Il problema dell'anno 2038 (Y2K38) spiegato

Cos'è il problema dell'anno 2038?

I timestamp Unix sono tradizionalmente memorizzati come intero con segno a 32 bit che conta i secondi dal 1° gennaio 1970 00:00:00 UTC. Il valore massimo di un intero con segno a 32 bit è 2,147,483,647, che corrisponde al 19 gennaio 2038 alle 03:14:07 UTC. Un secondo dopo, l'intero va in overflow a -2,147,483,648. Interpretato come timestamp Unix, quel valore negativo corrisponde al 13 dicembre 1901, riportando i sistemi colpiti quasi 137 anni nel passato.

I valori dell'overflow

• 2^31 − 1 = 2,147,483,647 (intero con segno a 32 bit massimo)
• 2,147,483,647 come data = 19 gennaio 2038 03:14:07 UTC
• 2,147,483,647 + 1 va in overflow a −2,147,483,648 (il valore a 32 bit più negativo)
• −2,147,483,648 come data = 13 dicembre 1901 20:45:52 UTC

Quali sistemi sono a rischio?

Il problema riguarda i sistemi che memorizzano i timestamp come interi con segno a 32 bit:

• Sistemi embedded e microcontrollori con time_t a 32 bit
• Codice C e C++ legacy compilato per target a 32 bit che usa time_t o int per i timestamp
• Vecchi kernel Linux (precedenti al 5.6) su hardware a 32 bit ancora in produzione
• Colonne TIMESTAMP di MySQL — limitate al 2038-01-19; usa invece DATETIME
• Alcuni protocolli di rete e formati di file che codificano i timestamp come valori a 32 bit
• Firmware in sistemi di controllo industriale e dispositivi IoT con vita utile di decenni

Quali sistemi sono sicuri?

La maggior parte del codice e dell'infrastruttura moderni non è già più interessata:

• Qualsiasi SO a 64 bit — Linux (glibc 2.34+ corregge anche l'hardware a 32 bit), macOS, Windows
• Python — i timestamp usano float a 64 bit, sicuri ben oltre l'anno 292 milioni
• JavaScript — Date usa float IEEE 754 a 64 bit, sicuro fino all'anno 275,760
• Go e Rust — usano int64 internamente, sicuri per miliardi di anni
• Java — java.time.Instant usa long (64 bit), sicuro fino all'anno ~292 milioni
• PostgreSQL TIMESTAMP — memorizza correttamente le date oltre il 2038
• MySQL DATETIME — intervallo 1000-01-01 a 9999-12-31, non interessato

FAQ sul problema dell'anno 2038

Cos'è il problema dell'anno 2038?

Il problema dell'anno 2038 (Y2K38) è un bug per cui i sistemi che usano interi con segno a 32 bit per memorizzare i timestamp Unix andranno in overflow il 19 gennaio 2038 alle 03:14:07 UTC. Il valore massimo di un intero con segno a 32 bit è 2,147,483,647. Un secondo dopo, l'intero passa a -2,147,483,648, che corrisponde al 13 dicembre 1901.

Qual è il timestamp Unix del 19 gennaio 2038?

Il timestamp Unix del 19 gennaio 2038 alle 03:14:07 UTC è 2,147,483,647 — il valore massimo di un intero con segno a 32 bit (2^31 - 1). È il momento esatto in cui avviene l'overflow dell'anno 2038 sui sistemi a 32 bit.

Y2K38 è lo stesso di Y2K?

No. Il Y2K (problema dell'anno 2000) era causato da programmi che memorizzavano gli anni con 2 cifre. Il Y2K38 è causato dalla memorizzazione dei timestamp Unix come interi con segno a 32 bit che vanno in overflow nel 2038. Cause diverse, sistemi interessati diversi.

Internet si romperà nel 2038?

Probabilmente non in modo significativo. La maggior parte dell'infrastruttura di internet è già migrata a sistemi a 64 bit. Il rischio si concentra su sistemi embedded, dispositivi IoT datati e software non aggiornato da decenni. Sistemi operativi, linguaggi e database moderni sono già sicuri.