I recenti avvenimenti che hanno coinvolto CrowdStrike e bloccato aeroporti e altri servizi in tutto il mondo, hanno fatto tornare sulla cresta dell'onda anche il bug dell'anno 2038, noto anche come Y2038 o Y2K38. Si tratta di una vera e propria minaccia per i sistemi informatici, che il 19 gennaio 2038 si ritroveranno catapultati nel passato, precisamente al 13 dicembre 1901. Ma qual è il motivo dietro questo bug che, come il "Millenium Bug" di diversi anni fa, potrebbe causare quella che secondo molti sarebbe una vera e propria "apocalisse digitale"?
Il bug ha origine dal modo in cui viene calcolato il tempo nei sistemi Unix e in molti programmi sviluppati in C. Questi sistemi contano i secondi trascorsi dal 1° gennaio 1970, utilizzando un numero intero a 32 bit. Il problema sorge quando questo contatore raggiunge il suo valore massimo, corrispondente alle 03:14:07 UTC del 19 gennaio 2038.
Superato questo limite, il contatore si azzera e ripartirà da un valore negativo, facendo "tornare indietro" l'orologio di sistema al 13 dicembre 1901. Ciò causerà inevitabilmente errori di calcolo e malfunzionamenti in molti programmi, creando gravissimi problemi all'infrastruttura informatica mondiale.
Il bug può manifestarsi anche prima del 2038 in software che devono gestire date future. Un esempio eclatante si è verificato nel 2006 con il server web AOLserver, che è andato in crash quando ha dovuto calcolare una data di scadenza oltre il limite critico.
Inutile dire che, ovviamente, gli sviluppatori di tutto il mondo sono già al lavoro per risolvere il problema ed evitare eventuali catastrofi. Ci sono diverse soluzioni, tra cui usare variabili a 64 bit per rappresentare il tempo, posticipando di fatto il problema di miliardi di anni, oppure passare a numeri interi unsigned a 32 bit, guadagnando però "solo" 68 anni, dato che il problema si ripresenterebbe nel 2106. Un'altra opzione è quella di includere millisecondi o microsecondi nel calcolo, estendendo la vita utile a circa 300.000 anni.
L'uso di una variabile 64 bit sembra essere, per ovvi motivi, la soluzione che più aggrada gli sviluppatori. La nuova variabile è già stata inserita nel kernel Linux 5.6, rilasciato ormai qualche anno fa, mentre negli scorsi mesi Debian, una delle distribuzioni Linux più diffuse e su cui tantissime altre si basano, ha annunciato il rilascio nella versione Unstable del parametro time_t a 64 bit.
Il bug dell'anno 2038 quindi si può evitare? La risposta è sì, ma è necessario prepararsi per tempo. Software e sistemi di archiviazione esistenti devono essere compatibili e, al momento, milioni di sistemi embedded sono ancora 32 bit. Il passaggio a sistemi 64 bit è costante e probabilmente, da qui al 2038, sarà quasi totale, ma tutto ciò che sfrutterà ancora i 32 bit, verrà colpito dal bug. La speranza è che, com'è accaduto per il precedente Millenium Bug, i problemi siano limitati e non abbiano alcun impatto sull'infrastruttura globale.
