19 gennaio 2038, ore 3:14.07 (UTC)
Chi si ricorda il millenium bug? Ricordo che la mattina del 1 gennaio 2000, l’unica cosa che andò in tilt a causa del millenium bug fu il cellulare Motorola del mio amico (lo aveva pagato una cifra)!
In realtà, quella del millenium bug fu una grossa manovra commerciale atta a svecchiare il parco computer del mondo.
Qualcosa di simile, però, sta per accadere: e questo si che è un "bel" millenium bug.
Chi è abituato a sviluppare in ambiente Unix, o con strumenti nati da quel contesto, avrà una certa familiarità con lo Unix Timestamp.
Lo Unix Timestamp conta quanti secondi sono trascorsi dalla Unix Epoch (1 gennaio 1970, ore 00:00.00 UTC).
Il problema sta nel fatto che gli attuali sistemi Unix tengono traccia di questo trascorrere del tempo utilizzando un intero di 4 byte. Un intero di 4 byte a 32-bit può assumere un valore massimo di 2.147.483.648. Se aggiungiamo questi oltre due miliardi di secondi alla Unix Epoch arriviamo alla data massima cui è possibile spingersi allo stato attuale e cioè 19 gennaio 2038, ore 3:14.07 (UTC).
Come facciamo a calcolare questo limite?
Un intero di 4 byte su un sistema a 32-bit può assumere 232 valori tra positivi e negativi. Visto che i secondi vanno aggiunti per calcolare le date dalla Unix Epoch, allora vanno presi in considerazione solo i valori positivi; perciò il valore totale va diviso per due: 232/2 = 2.147.483.648.
Quello che accadrà quel fatidico giorno sarà che i sistemi Unix/Linux subiranno un "reset" e le date ricominceranno ad essere contate dal primo secondo del 1970 cioè dalla Unix Epoch.
In realtà questo è un falso allarme, perché per quella data tutti i sistemi saranno svecchiati con un sistema tecnologicamente avanzato o semplicemente utilizzando core a 64-bit, il che rimanderebbe il problema per un bel pò.
Con un core a 64-bit un intero di 8 byte potrà assumere 264 valori tra positivi e negativi. Sempre per lo stesso ragionamento di prima, per vedere il limite vanno presi in considerazione solo i valori positivi, perciò dal computo totale vanno tolti la metà: 264/2 = 9,22337204 × 1018, o per chi mastica poco le potenze 9.223.372.036.854.775.808.
Tuttavia, molti software che girano su sistemi Unix/Linux o sono sviluppati con strumenti che sfruttano lo Unix Timestamp - come PHP o anche MySQL - potrebbero avere già oggi problemi nel computare date che vanno oltre il limite.
Non sono pochi i software che fanno proiezioni finanziare per il futuro e il 2038 è "solo" tra 30′anni: in ambito finanziaro sono pochi anni. Già oggi risultano numerosi i software che stanno avendo problemi.
Ad esempio, nel maggio 2006 AOLserver ha subito un primo problema dovuto a questo bug. Un software che usava una data pari a un miliardo di secondi nel futuro per classificare le richieste ad un database come "senza scadenza". Alle 21:27.28 del 12 maggio 2006 (un miliardo di secondi prima della data fatidica del 19 gennaio 2038) il sistema di calcolo della data superò il limite critico e causò un crash del sistema.
Come andrà a finire?
