Il codice binario ha i suoi vantaggi – e i suoi svantaggi. Ricordi il 1999, quando – tra la mania delle Spice Girls e la raccolta frenetica dei Beanie Babies per qualche motivo – tutti erano in preda al panico per il Millennium Bug? La paura era che, passando dal ’99 al ’00, i computer non sarebbero stati in grado di capire che il secolo era cambiato; la data sarebbe stata reimpostata al 1900 e i sistemi dipendenti dai computer in tutto il mondo sarebbero andati in crash. Il risultato? Qualsiasi cosa, da “alcuni errori divertenti sui calendari elettronici” a “il crollo letterale della civiltà come la conosciamo”, a seconda di chi chiedessi. Alla fine, ovviamente, il nuovo anno è stato piuttosto tranquillo – grazie in gran parte a uno sforzo diffuso e concertato dietro le quinte per evitare il disastro. E questo è stato tutto, giusto? Navigazione tranquilla da allora in poi? Aspetta – c’è un sequel?
Qual è il problema del 2038? Il 19 gennaio 2038: il giorno in cui il tempo finisce. Almeno, se sei un computer che utilizza il tempo Unix a 32 bit – che quasi tutti fanno. “Un intero a 32 bit con segno può memorizzare solo numeri da -2147483648 a 2147483647,” spiega Tanium, una società di gestione dei sistemi e sicurezza informatica con sede a Kirkland, Washington. “Ciò significa che il timestamp più alto che questi sistemi possono gestire è 2147483647, che corrisponde al 19 gennaio 2038, alle 03:14:07 UTC.” Questi numeri non sono casuali – per quanto arbitrario possa sembrare 2.147.483.648 agli occhi umani, per un computer che lavora in base-2, è una grande pietra miliare: è quando l’orologio segna 100.000.000.000.000.000.000.000.000.000.000. Per un sistema a 32 bit, sono semplicemente troppi numeri da gestire – quindi il contatore fa l’unica cosa disponibile, e torna tutto all’inizio. “Il timestamp traboccherà e diventerà un numero negativo, il che farà sì che la data e l’ora siano sbagliate,” spiega Tanium. “Ad esempio, il timestamp per [03:14:08 UTC] del 20 gennaio 2038, in tempo Unix è 2147483648. Poiché questo non è un timestamp valido utilizzando il formato Unix, traboccherà e diventerà -2147483648, che corrisponde al 13 dicembre 1901, alle 20:45:52 UTC. Questo è il bug dell’anno 2038.”
Dovremmo preoccuparci? Dopo tutto il trambusto intorno al problema Y2K, spereresti che avremmo imparato la lezione quando si tratta di preparazione. Dopotutto, conosciamo il bug del 2038 almeno dal 2006, quando un problema simile ha colpito il software che supportava il server web di AOL – sicuramente, 32 anni sono più che sufficienti per trovare una soluzione? In realtà, c’è una soluzione piuttosto semplice al problema del 2038, ed è proprio davanti ai nostri occhi: “La soluzione è passare al supporto del tempo a 64 bit,” ha scritto Paul Budde, CEO della società di consulenza indipendente Paul Budde Consulting, in Independent Australia nel 2022. “Con 64 bit, c’è più che abbastanza spazio per memorizzare i valori temporali ben oltre il futuro prevedibile, anche se vengono utilizzati valori temporali ad alta risoluzione (basati su nanosecondi).” Sessantaquattro potrebbe non sembrare molto più grande di trentadue – ma quando si tratta di esponenti, è la differenza tra “13 anni” e “circa 21 volte l’età dell’universo”. Passare al sistema di archiviazione più grande significherebbe, è giusto dire, spostare il problema così lontano nel futuro che potrebbe anche essere completamente risolto. Quindi, abbiamo fatto il passaggio in massa? Beh… no. “Diversi tipi di database, inclusi i database relazionali e NoSQL” si basano ancora sul tempo a 32 bit, sottolinea Tanium, così come qualsiasi programma scritto in linguaggi basati su C, come C++ e PHP. I dispositivi che eseguono Windows, Linux, Android o iOS potrebbero essere a rischio, notano, così come “dispositivi medici, sistemi di controllo industriale per strutture come centrali elettriche, sistemi di trasporto, automobili con sistemi di bordo che monitorano il controllo elettronico della stabilità e il controllo della trazione, router, switch, sensori e dispositivi IoT [Internet of Things] come elettrodomestici intelligenti.” In generale, ha il potenziale per essere estremamente dirompente. Quindi, quanto siamo pronti per questo?
Siamo pronti per il bug del 2038? È difficile dire esattamente quanto siamo pronti per il 2038 – man mano che vengono rilasciati nuovi sistemi operativi, molti sono dotati di tempo a interi a 64 bit come standard al giorno d’oggi. Ma il problema più grande è con i sistemi già esistenti: passare da 32 a 64 bit è, per i sistemi operativi basati su sorgente, “tutt’altro che banale,” ha scritto Michał Górny, sviluppatore per la distribuzione Linux Gentoo, in un post sul blog del 2024 sull’argomento. “Soprattutto, stiamo parlando di un cambiamento ABI di rottura. È tutto o niente,” ha scritto. “Se una libreria utilizza time_t nella sua API, tutto ciò che si collega ad essa deve utilizzare la stessa larghezza di tipo […] mescolare programmi e librerie time32 e time64 può portare a orribili bug di runtime.” Fondamentalmente, passare improvvisamente dai timestamp a 32 bit a quelli a 64 bit lascerebbe un sacco di programmi già esistenti a lottare per capire il nuovo sistema. Sarebbe come se fossi improvvisamente trasportato nell’Inghilterra medievale e volessi comunicare con i locali: tecnicamente, parleresti la stessa lingua, ma praticamente? Non sapresti esattamente cosa sta succedendo in ogni momento. E questo è solo l’inizio. Abbiamo avuto – e abbiamo ancora – molto tempo per prepararci al problema del 2038, e quando colpirà, “tutti i sistemi informatici attuali saranno stati aggiornati ben prima di quel momento,” ha previsto Budde. “Tuttavia […] la maggior parte di questi problemi sarà nei vecchi programmi che nessuno si ricorda mai di aggiornare e testare,” ha avvertito – “non è qualcosa che gli ingegneri informatici vorrebbero lasciare all’ultimo minuto, come è successo con il problema Y2K.” Anche se ogni sistema dipendente dal tempo a 32 bit viene trovato e aggiornato, gli effetti a catena di tali cambiamenti su larga scala “dovranno essere prima mappati e poi accuratamente ricercati per trovare le soluzioni appropriate che prevengano effetti collaterali indesiderati,” ha avvertito Budde. “E a loro volta, queste soluzioni potrebbero creare i propri effetti collaterali.” Quindi, uh… sì. Incrociamo le dita, eh, gente?
Imparare dai nostri errori Ascolta: cerchiamo di essere ottimisti. Diciamo che risolviamo completamente il problema del 2038, e tutti gli effetti a catena associati, e nessun sistema computerizzato ha nemmeno un blip alle 03:14:08 del 20 gennaio 2038. Possiamo tutti tirare un sospiro di sollievo e dimenticare tutta la faccenda? Beh, possiamo – ma probabilmente non dovremmo. Solo pochi decenni dopo, affronteremo di nuovo la stessa cosa: il 7 febbraio 2106, alle 06:28:15 UTC, il problema colpirà tutti quei sistemi che memorizzano il tempo come un intero a 32 bit senza segno – cioè, utilizzando lo stesso numero di cifre, ma senza dare nessuna di esse ai numeri negativi. Avanti veloce di un periodo di tempo simile, e Windows affronterà la sua versione del bug: “Windows NT utilizza un intero a 64 bit per tracciare il tempo,” nota HowStuffWorks. “Tuttavia, utilizza 100 nanosecondi come incremento e l’inizio del tempo è il 1° gennaio 1601, quindi NT soffre del problema dell’anno 2184.” Oltre a ciò, c’è un problema del 2262, un problema del 2262 e persino un problema del 2446, tutti legati alle ipotesi dei programmatori del passato su quanto tempo continueremmo a utilizzare i protocolli inventati a metà del XX secolo. Diremmo che è stato miope da parte loro – ma ammettiamolo: presto avremo problemi molto più grandi di cui occuparci in ogni caso.