Dopo Il Millennium Bug, Arriverà Il Bug Dell'Anno 2038

Passato indenne il Millennium Bug del 2000, c'apprestiamo (o meglio, mancano ancora un po' di anni) a vivere quello del 19 Gennaio 2038.
Però manca ancora un bel po' di tempo eh?
Ad ogni modo a causarlo sarebbero i processori a 32 bit quindi nessun problema per coloro che usano sistemi a 64 bit(per la verità tra una ventina d'anni i computer saranno drasticamente diversi da quelli di ora ed è assolutamente improbabile che si rimanga con questi processori).


BUG 2038
Il problema comunque scatterebbe a una data e un’ora specifica: 19 gennaio 2038 alle 03:14:07 (fuso orario di Greenwich).
Da quel momento in poi, i computer che utilizzeranno ancora sistemi a 32 bit non saranno in grado di stabilire la differenza tra il 2038 ed il 1970 (anno di partenza da cui sono settati gli attuali computer).
I sistemi Unix, infatti, non possono calcolare le date successive al 2038.
Questo perché tengono traccia del tempo utilizzando un intero di 4 byte che rappresenta il numero dei secondi dal primo gennaio 1970.
In pratica, un intero di 4 byte ha un valore massimo di 2.146.483.547: proprio questo tempo (conosciuto come “tempo massimo”) corrisponde al 19 gennaio 2048, ore 3.14.07.
I sistemi Unix, infatti, non erano stati toccati dal Millennium Bug(del 2000), ma ora ne vanno incontro ad un altro.
Il problema è che molte macchine che hanno come sistema operativo Unix/Linux sono quelle che controllano le principali arterie del mondo tecnologico, dall’aeronautica a internet.
Quello che accadrà sarà un semplice “reset” del tempo a 0, quindi al primo minuto del 1970.
Perché proprio 2.147.483.647? I computer misurano il tempo in secondi.
Quindi, 2.147.483.647 sono i secondi compresi nell’intervallo tra il primo gennaio 1970 (Tempo Unix) ed il 19 gennaio 2038 alle 03:14:07.
Il problema è generalizzato perché i processori, anche se di differenti dimensioni e capacità, funzionano tutti allo stesso modo, sia su device fissi sia su mobile.
Alcuni processori potrebbero continuare a funzionare bene con una data sbagliata mentre altri smetterebbero drasticamente di lavorare.


DA COSA è GENERATO IL BUG?
La maggioranza dei sistemi informatici mondiali (anche la stessa “struttura” sulla quale si appoggia internet) è basata su UNIX, il famoso sistema operativo open source dal quale sono derivati Linux e anche i prodotti della Apple.
Il sistema operativo UNIX memorizza le date in un formato definito dallo standard POSIX.
In pratica la data è memorizzata in un numero che rappresenta il numero di secondi a partire dalla mezzanotte del 1° Gennaio 1970, tale data viene anche chiamata “epoca” (The Epoch), per cui ogni secondo che passa, questo numero incrementa di una unità.
Gli orari sono in formato UTC, che corrisponde all’orario GMT (quello di Greenwich insomma).
La data viene memorizza in un numero a 32 bit e i sistemi colpiti saranno quelli che usano la variabile "signed".
Fortunatamente, non tutti i sistemi UNIX utilizzano il tipo signed e usano quindi il tipo unsigned che porta a non avere problemi su queste macchine (o meglio a spostarlo alle 06:28:15 di Domenica 7 Febbraio 2106) .
Un numero a 32 bit di tipo signed prevede che il numero positivo più grande memorizzabile sia 2147483647 che in base al sistema POSIX corrisponde  alle ore 03:14:07 di martedì 19 Gennaio 2038.
Un secondo dopo, come già spiegato, il numero verrà incrementato ancora di 1 e di conseguenza verrà posto ad 1 il bit più significativo di  tale numero(numero negativo).
Per cui facendo due calcoli col complemento a due il numero vale -2147483648 che nella fattispecie viene interpretato dal sistema POSIX come le ore 20:45:52 del giorno Venerdì 13 Dicembre 1901.
Questo fatto causerà enormi problemi in tutti gli ambiti in quanto dopo le 03:14:07 di martedì 19 Gennaio 2038 i sistemi UNIX crederanno di “essere tornati indietro nel tempo” al 1901 con conseguenze catastrofiche dal momento che oramai tutto è gestito da computer e tutto si appoggia alla rete internet.


SOLUZIONI
Detto del passaggio a sistemi a 64 bit, vanno fatte alcune considerazioni.
Cambiare il valore di time.h (che controlla appunto il tempo e come detto è un numero intero a 32 bit) 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 time.h in un intero unsigned, permetterebbe di rimandare il problema al 7 febbraio 2106, causando comunque problemi a molti programmi.
Molti sistemi operativi per sistemi a 64-bit usano già dei numeri interi a 64-bit per il time.h.
Il passaggio a questo tipo di 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.
L'uso di time.h 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.
L'uso di un valore di tipo signed a 64-bit sposterebbe l'emergere del problema in avanti nel tempo di circa 290 miliardi di anni.
Sono state avanzate anche varie proposte alternative, alcune delle quali in uso, per sfruttare questo spostamento eccessivo della data massima calcolabile: tra queste, includere nel calcolo delle ore i millisecondi o i microsecondi, abbreviando la vita utile delle macchine a 300.000 anni.