Probabilmente ricorderete il panico che circondava l’anno 2000. I media hanno avuto una giornata campale nel prevedere il collasso globale quando l’orologio ha segnato il 2000. Ma mentre molti sistemi legacy sono stati rattoppati allora, un timer diverso sta ancora ticchettando sullo sfondo di gran parte della moderna Internet. Si chiama problema dell’anno 2038. Ed è radicato nel modo in cui i linguaggi di programmazione C gestiscono il tempo.
La maggior parte delle persone presume che il problema riguardi anni a due cifre come Y2K. Non lo è. Il problema principale è più profondo nel codice. Nello specifico, il modo in cui i programmi C memorizzano i dati sulla data.
Il limite di 32 bit
Ecco la realtà tecnica. La libreria dell’ora standard in C utilizza un intero con segno a 4 byte per tenere traccia del tempo. Sono 32 bit. Questo formato definisce “epoca epocale” come a partire dal 1 gennaio 1970 alle 00:00 UTC. Ogni secondo successivo a quel momento viene memorizzato come un semplice numero.
Ad esempio, il timestamp “919642718” rappresenta 919 milioni di secondi dopo l’epoca. Ciò avviene il 21 febbraio 1999. È conveniente perché sottraendo un timestamp da un altro si ottengono i secondi esatti tra due eventi. Le biblioteche poi convertono quei secondi in minuti, ore o anni.
Ma c’è un limite massimo.
Un intero con segno a 32 bit ha un valore massimo di 2.147.483.647. Una volta che il contatore raggiunge zero secondi dopo il 1 gennaio 1970, si ribalta.
Questo rollover avviene il 19 gennaio 2038.
Dopo tale data, il numero intero va in overflow. Passa a un numero negativo. Per un sistema che fa affidamento su questo formato, quel valore negativo è una data non valida. È effettivamente un problema tecnico nella matrice per qualsiasi software che non sia stato aggiornato.
Perché è più facile dell’anno 2000
La buona notizia? Risolvere questo problema non è così complicato come gli incubi del mainframe della fine degli anni ’90.
Nel 2000, molti sistemi non standardizzavano il modo in cui archiviavano le date. Alcuni usavano MM-GG-AA. Altri hanno utilizzato AA-MM-GG. La mancanza di un formato universale significava che gli sviluppatori dovevano scovare il codice in ogni applicazione e modificare manualmente la logica della data.
Il problema dell’anno 2038 è più pulito.
La libreria dell’ora standard incapsula l’intero processo di cronometraggio. Definisce i propri tipi e funzioni. Quindi, i programmi ben scritti possono essere semplicemente ricompilati. Gli ingegneri devono semplicemente sostituire la libreria con una versione che utilizza una dimensione in byte maggiore.
Ad esempio, il passaggio da un numero intero a 4 byte a un numero intero a 8 byte espande l’intervallo in modo significativo. Un intero con segno da 8 byte può contare ben oltre 2038 senza traboccare. È un aggiornamento software. Non una sostituzione dell’hardware. Non una riscrittura del codice. Uno scambio di biblioteca.
Windows e Mac: timer diversi, problemi diversi
Non tutti i sistemi utilizzano il formato C a 32 bit. Diversi sistemi operativi hanno le loro peculiarità.
Windows NT, ad esempio, utilizza un numero intero a 64 bit. Tiene traccia del tempo con incrementi di 100 nanosecondi. Ma si inizia a contare dal 1° gennaio 1601, non dal 1970. Ciò spinge la data di superamento molto più lontano. Windows probabilmente raggiungerà il suo limite intorno all’anno 2184.
Apple ha adottato un approccio diverso. Secondo la documentazione di Apple, macOS è strutturato per rimanere valido fino all’anno 29.940. Sono circa 27.000 anni da oggi. Quindi, se utilizzi un Mac, non devi preoccuparti che il tuo calendario si blocchi nel 2038.
Chi altro è a rischio?
I sistemi basati su Unix sono la preoccupazione principale. Ma non sono soli.
Anche i sistemi embedded sono vulnerabili. Molti dispositivi IoT, controller industriali e server di database meno recenti si basano sullo stesso formato temporale a 32 bit. Se non sono stati aggiornati, inizieranno a interpretare erroneamente le date successive al 19 gennaio 2038.
Le soluzioni a breve termine potrebbero comportare l’applicazione di patch al software per gestire correttamente i valori temporali negativi. Ma quella è una benda. La soluzione permanente richiede l’aggiornamento a un formato orario a 64 bit.
La domanda non è se il codice si romperà. Dipende se i sistemi che eseguono quel codice verranno aggiornati prima che scada il tempo.
La maggior parte dell’infrastruttura su cui facciamo affidamento si sta già muovendo verso il cronometraggio a 64 bit. Ma non tutto lo è. Vecchi server. Attrezzature industriali preesistenti. Una certa logica incorporata. Questi sono gli anelli deboli.
Quando arriverà il 19 gennaio 2038, l’orologio raggiungerà il suo limite. Per alcuni sistemi, sarà un non-evento. Per altri sarà una sosta dura. Non ci sarà molto tempo per correggere il codice se aspetti fino all’ultimo minuto.
