Tutti guardano con preoccupazione al 2035 come l’anno di una possibile svolta epocale: ammesso e non concesso che assisteremo davvero alla fine del motore termico, ci si domanda cosa succederà, quanto dovremo rivoluzionare le nostre abitudini e con quali effetti potenzialmente critici. Ma io vi dico: lasciate stare le auto elettriche, la vera data che dovrebbe davvero metterci in allarme è il 19 gennaio 2038, alle ore 03:14:07 UTC.
No, non è una profezia Maya 2.0, ma il giorno in cui il tempo, così come lo conosciamo sui nostri dispositivi, rischia di impazzire.
Sì, avete capito bene. Se pensavate che il passaggio alle auto elettriche fosse un problema, aspettate di vedere cosa succederà quando computer, server e dispositivi di mezzo mondo si convinceranno di essere tornati nel 1901.
Questa storia vi ricorda qualcosa? Se avete qualche anno sulle spalle, forse sì. Ricordate il panico da Millennium Bug, meglio noto come Y2K? Alla fine degli anni ‘90 c’era chi temeva che alla mezzanotte del 31 dicembre 1999 i computer sarebbero impazziti, causando il collasso di banche, ospedali e addirittura centrali nucleari. Il problema nasceva dal fatto che molti sistemi informatici registravano le date con solo due cifre per l’anno: il 99 di 1999 sarebbe diventato 00, mandando tutto in tilt. Alla fine, però, il disastro fu evitato con largo anticipo grazie agli aggiornamenti software e a costose revisioni dei sistemi.
Questa volta però, più di trent’anni dopo, dovremo affrontare un problema simile, ma con implicazioni nettamente più insidiose: il problema dell’Anno 2038.
Perché il tempo finirà nel 2038?
Per capire cosa sta succedendo, facciamo un passo indietro e parliamo dello Unix Timestamp. Ogni volta che un computer ha bisogno di registrare una data, non lo fa come noi esseri umani, con giorni, mesi e anni, ma conta il tempo in modo molto più semplice ed efficiente.
Tutto inizia il 1° gennaio 1970, alle 00:00:00 UTC, quello che gli informatici chiamano “l’Epoca Unix”. Da quel momento, ogni secondo viene conteggiato come un numero intero crescente. Così, per esempio, il 1° gennaio 1971 corrisponde a 31.536.000, che è esattamente il numero di secondi passati dall’inizio dell’epoca Unix.
Semplice, veloce e perfetto. Almeno finché non ci si rende conto che questo numero viene memorizzato in una variabile a 32 bit con segno, il che significa che può rappresentare al massimo il valore 2.147.483.647. E indovinate un po’? Questo limite verrà raggiunto il 19 gennaio 2038 alle 03:14:07 UTC.
Da lì in poi, il contatore non potrà più avanzare e tornerà a valori negativi, facendo credere ai sistemi che siamo piombati nel 1901.
Cosa potrebbe succedere?
Ora, potreste pensare: “Ok, il numero arriva al massimo, e quindi? Qual è il problema?”. Il guaio è che tantissimi sistemi nel 2038 dipenderanno ancora da questo metodo per calcolare il tempo, e se la data diventa improvvisamente il 1901, gli effetti possono essere imprevedibili.
Immaginate un bancomat che rifiuta il vostro prelievo perché, secondo lui, la vostra carta di credito è scaduta da più di un secolo. Oppure un server che manda all’aria registri contabili, fatture e transazioni bancarie perché le date non hanno più senso. O, ancora peggio, dispositivi di sicurezza, sistemi di trasporto, router e persino macchinari ospedalieri che smettono di funzionare perché il software non sa come gestire il tempo.
E non pensate che sia solo un problema di computer e server. Molti dispositivi cosiddetti embedded, come i sistemi di navigazione delle auto, gli impianti di controllo industriale e persino alcuni elettrodomestici intelligenti, usano Unix Timestamp a 32 bit. Se nessuno li aggiorna, potrebbero trasformarsi in cimeli inutilizzabili nel giro di quindici anni.
Come si può risolvere?
Per fortuna, a differenza del Millennium Bug, abbiamo più tempo per prepararci. La soluzione più semplice è passare a interi a 64 bit, che ci permetterebbero di contare i secondi fino all’anno 292 miliardi (a quel punto avremo probabilmente altri problemi più urgenti).
Molti sistemi moderni, specialmente quelli basati su architetture a 64 bit, hanno già risolto il problema. Tuttavia, il vero pericolo viene dai sistemi più vecchi, quelli che “funzionano ancora bene” e che nessuno pensa di aggiornare. Come sempre, il rischio non è nella tecnologia più avanzata, ma in quella che nessuno si preoccupa di cambiare finché non smette di funzionare.
OK, niente panico allora...?
C'è molto tempo e anche molta consapevolezza su questa scadenza, tanto che possiamo tutti stare abbastanza tranquilli ed evitare toni apocalittici o millenaristi. Chi lavora nel nostro settore sa già benisismo come controllare i propri sistemi e come applicare le modifiche e gli aggiornamenti necessari, mettendo mano a tutto ciò che ancora usa timestamp a 32 bit. E per tutti gli altri… beh, segnate la data e sperate che, quando quel giorno arriverà, qualcuno abbia fatto il suo dovere. E se tutto dovesse andare storto, almeno avrete una scusa perfetta per prendervi un giorno di ferie! 😆
