19 Gennaio 2038, ore 03:14:07 (GMT) della mattina.

Oggi sono ossessionato dai limiti superiori dei programmi e così ho dato a fondo a tutta la mia curiosità sul tema del tempo nei sistemi Unix. Per capire il resto dell’articolo, è da premettere che il tempo in questo tipo di sistemi è rappresentato da una variabile contenente il numero di secondi che sono trascorsi dalla mezzanotte (UTC) dell’1 gennaio 1970.

Per analizzare il bug è però doveroso fare una piccola spiegazione di informatica: un intero a 32bit (signed, e quindi con possibilità di avere un segno negativo) rappresenta un valore massimo pari a 2.147.483.647 numeri positivi (e altri 2.147.483.648 numeri negativi, ma finché non inventeranno la data negativa non servono a molto..) dunque sono 2.147.483.647 secondi che corrispondono a 35.791.394 minuti, cioè 596.523 ore, 24.855 giorni e quindi, circa, 68 anni.

Ora basta fare un semplice 1970 (anno di partenza) + 68 (numero massimo memorizzabile da un intero a 32bit) per trovare la data sospirata: 2038, più precisamente il 19 Gennaio 2038 alle ore 3, 14 minuti e 8 secondi.
Raggiungendo quella data, il contatore va in overflow, cioè non registra assolutamente la data giusta, ma segna i secondi negativi. In sintesi, arrivati al 2.147.483.647 si passerà al -2.147.483.647esimo secondo, continuando poi a segnare secondi negativi che vengono sottratti a una sorta di countdown fittizio che può durare altri 68 anni…

La differenza principale con il Millennium Bug è quella che mentre il millennium bug poteva essere, nella maggior parte dei casi, un errore di interpretazione della data (interpretare un 1-1-00 come il 1900, e non come il 2000), questo tipo di bug è più “grave”, poichè va ad incidere sulla memorizzazione stessa del campo. E se il Millennium Bug è stato ampiamente sovrastimato (da ricordare che una commissione del Senato statunitense a fine 1999 aveva altamente sconsigliato ai propri cittadini di trovarsi in paesi come l’Italia, la Russia e la Cina, considerati assolutamente non adeguati nell’aggiornamento software. Ora l’Italia viene citata dai detrattori del Millennium Bug come esempio banale di come, pur limitando i lavori di intervento sui sistemi, non sia successo proprio nulla), il Y2K38 non è affatto da sottovalutare, anche a 30 anni di distanza.

Risolvere un problema come questo non è affatto semplice.

Cambiare il valore della variabile per usare un sistema a 64-bit renderebbe il sistema incompatibile con software, sistemi di memorizzazione e tutti gli strumenti che usano una rappresentazione binaria del tempo. Cambiare il valore in un intero non unsigned (senza segno, e quindi non in grado di memorizzare numeri negativi, valori che nella rappresentazione delle date non hanno assolutamente senso), permettendo di rimandare il problema al 2106, causerebbe, comunque, problemi a molti programmi. Usare un valore di tipo signed a 64-bit sposterebbe l’emergere del problema in avanti nel tempo di circa 290 milioni di anni, spostando la data addirittura al di là della previsione di vita del sistema solare.

Molti sistemi operativi per sistemi a 64-bit usano già dei numeri interi a 64-bit per la rappresentazione del tempo. Il passaggio a questo tipo i architetture è in corso, e ci si aspetta che sia completo prima del 2038. Tuttavia, ancora oggi esistono centinaia di milioni di sistemi a 32 bit sul mercato, di cui molti in sistemi integrati, e non è affatto certo che vengano rimpiazzati prima del 2038.

Nonostante l’attuale trend di aggiornamento dei computer ogni 18-24 mesi, i computer integrati possono lavorare senza interruzioni per tutta la vita del sistema che controllano. L’uso a 32 bit è anche stato inserito in vari formati di file, cosa che comporta la persistenza del problema anche oltre la vita delle macchine stesse.

Niente allarmismi, però… c’è tutto il tempo per elaborare soluzioni, aggiornare i sistemi e quant’altro, pur considerando il fatto che, nel Maggio 2006, un primo problema è già avvenuto nei server Aol. Il “problema” è quello che, nonostante la previsione sia ampiamente anticipata, questo tipo di errore, potenzialmente molto più dannoso rispetto a quello del 2000, è meno comprensibile dal grande pubblico (la spiegazione del Y2K è abbastanza banale, quella del Y2K38 è decisamente più complessa). Basterà un pò di informazione mirata, un pò di preveggenza dai sistemisti, un pò di sana analisi da parte dei programmatori (sarebbero da eliminare le frasi del tipo “questo software non girerà sicrauemente più fra 30 anni”… l’Y2K ha dimostrato che a distanza di 30 anni erano ancora molte le applicazioni scritte decine di anni prima) e passerà sicuramente la paura.
E per concludere, mai detto fu più azzeccato: chi vivrà, vedrà…

P.S.: E c’è pur sempre il bug Y10K, o bug dell’anno 10.000.

Popularity: 11% [?]