Bug dell'anno 2038

Esempio che mostra l'azzeramento della data.

Il Bug dell'anno 2038 è un noto bug informatico che potrebbe avere ripercussioni su alcuni software nell'anno 2038.

Il problema riguarda programmi che usano la rappresentazione POSIX per calcolare il tempo: questa calcola la data del sistema a partire dal numero di secondi a partire dal 1 gennaio 1970 (ignorando i secondi intercalare). Questo tipo di sistema è lo standard per i sistemi Unix, e colpisce anche software per altri sistemi operativi che siano stati sviluppati in C. Sulla maggior parte dei sistemi a 32 bit il valore del dato time_t usato per questo calcolo è un numero intero a 32 bit di tipo signed. Usando questo sistema, la data più avanzata rappresentabile a partire dal 1/1/1970 sono le 03:14:07 di martedì 19 gennaio 2038. Dopo questo momento, il contatore supererebbe il valore massimo, e verrebbe considerato come un numero negativo. I computer leggeranno la data non come 2038 ma come 1901 (precisamente, le 20:45:52 di venerdì 13 dicembre 1901), causando errori di calcolo. ^[1] "Year 2038" è chiamato anche "Y2038", "Y2K38", o "Y2.038K" nel linguaggio specialistico.

Indice

[modifica] Problemi noti

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. ^[2]^[3]

[modifica] Soluzioni

Risolvere il problema sui processori/sistemi operativi esistenti non è semplice.

Cambiare il valore di time_t 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_t in un intero unsigned, permettendo di rimandare il problema al 2106, causerebbe comunque problemi a molti programmi.

Molti sistemi operativi per sistemi a 64-bit usano già dei numeri interi a 64-bit per il time_t. 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, 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 di time_t 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.

Usare un valore di tipo signed a 64-bit sposterebbe l'emergere del problema in avanti nel tempo di circa 290 miliardi di anni, spostando la data addirittura al di là della previsione di vita del sistema solare.

Sono state avanzate anche una serie di 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 "soli" 300.000 anni ^[4]