Cos’è Epochalypse, il prossimo grande bug che rischia di bloccare tutti i computer nel 2038

Il blackout informatico globale di venerdì 19 luglio 2024 non è stato il primo e né sarà l’ultimo problema che il mondo digitale si troverà ad affrontare. All’orizzonte, oltre alle sempre più frequenti minacce di attacchi informatici e alle tante vulnerabilità (come quella emersa con l’aggiornamento dell’antivirus di CrowdStrike che ha bloccato milioni di pc Windows nel mondo), c’è una questione conosciuta con il nome di Epochalypse e che in futuro avrà ripercussioni su alcuni sistemi operativi a 32 bit.

Epochalypse, noto anche come il problema dell’anno 2038 (o Y2038) è un bug informatico che riguarda la rappresentazione del tempo nelle date relative all’anno 2038 e successivi. Simile al Millenium Bug (Y2K) che si verificò perché i primi computer risparmiavano costoso spazio di memoria, contando solo le ultime due cifre dell’anno, non distinguendo quindi tra 1900 e 2000, anche Epochalypse ci catapulterà nel secolo scorso, e precisamente alle 20:45:52 UTC del 13 dicembre 1901, una data che nella rappresentazione dei sistemi operativi Unix a 32 bit (ma anche in software per sistemi operativi sviluppati in C) corrisponde alle ore 03:14:07 di martedì 19 gennaio 2038.

In altre parole, dopo le 03:14:07 UTC del 19 gennaio 2038 (ma anche se ai pc viene richiesto di operare con date corrispondenti o successive a quell’istante), il contatore supererà il valore massimo consentito, restituendo una data errata. Questo perché i sistemi a 32 bit contano il passare del tempo misurando il numero di secondi trascorsi dalla mezzanotte del 1° gennaio 1970, un momento noto come “Epoca” (da qui il nome Epochalypse): i secondi trascorsi vengono quindi memorizzati come un numero intero a 32 bit (sequenza binaria di 32 zeri e uno) che di fatto raggiunge il suo valore massimo proprio alle 03:14:07 del 19 gennaio 2038.

Cos’è Epochalypse, il bug dell’anno 2038

Epochalypse, come detto, è un bug informatico che riguarda la gestione delle date relative all’anno 2038 e successive. Nello specifico, il problema risiede nella rappresentazione del tempo utilizzata nei sistemi che lo standard digitale Unix time, che conta i secondi trascorsi dalle 00:00 UTC del 1° gennaio 1970 e li memorizza in un numero intero a 32 bit. Ciò implica che il dato “time.h” – che tiene conto di questo conteggio con un valore che può assumere segno positivo o negativo – possa misurare un intervallo di tempo limitato, raggiungendo la soglia massima consentita alle ore 03:14:07 UTC del 19 gennaio 2038.

Dopo quell’istante, il contatore andrebbe ad indicare un numero intero negativo, per cui i computer restituirebbero una data non corrispondente al 2038 ma al 1901, a partire dalle 20:45:52 UTC del 13 dicembre 1901.

Sebbene debbano trascorrere ancora 14 anni e gli informatici stiano cercando un modo per risolvere il problema, il bug si può manifestare anche prima del 2038, quando ai pc viene richiesto di operare con date corrispondenti o successive all'istante incriminato: ciò è già accaduto, ad esempio, nel 2006, al server web AOLserver, che gestiva le richieste senza scadenza al proprio database, assegnando alle stesse una data di scadenza pari ad un miliardo di secondi dopo la loro immissione. In quell’occasione, alle 21:27:28 del 12 maggio 2006, esattamente un miliardo di secondi prima delle 03:14:07 del 19 gennaio 2038, il sistema di calcolo superò il limite critico, restituendo una data di scadenza nel passato e causando un crash del sistema.

Come potrebbe essere risolto il bug

Risolvere il problema dell’Epochalypse 2038 non è semplice, per le tante combinazioni esistenti di processori, sistemi operativi e file system. Una soluzione potrebbe essere rappresentata dalla variazione del tipo di “time.h” da 32 bit a 64 bit, che sposterebbe il bug avanti nel tempo di circa 290 miliardi di anni, rischiando tuttavia di rendere il sistema incompatibile con software, sistemi di memorizzazione e tutti gli strumenti che usano una rappresentazione binaria del tempo.

Un’altra strategia potrebbe essere quella di lasciare il “time.h” un intero a 32 bit, ma senza la possibilità di assumere segno positivo o negativo (tipo unsigned) il che posticiperebbe il problema di 68 anni, spostandolo al 7 febbraio 2106, e causerebbe comunque problemi a molti programmi.