t_time: Unix e il bug del 2038

t_timeLa mezza notte del 31 dicembre del 1999 destó molte preoccupazioni, sia per la paura della fine del mondo, ma anche per il famigerato millennium bug che avrebbe mandato in tilt i sistemi informatici di tutto il mondo. Il millenium bug riguardava il modo in cui i computer trattavano l’abbreviazione dell’anno, il 1999 veniva abbreviato in 99 quindi il 2000 sarebbe diventato 00 mettendo in crisi il computer, in quanto anche 1900 avrebbe avuto la stessa abbreviazione. Come è andata a finire? Non è successo nulla, dopotutto siamo ancora qui.

Il bug del 2038 invece, è più pericoloso perché riguarda il modo in cui la data viene memorizzata. Tale problema riguarda però i sistemi Unix, in quanto memorizzano la data in una variabile chiamata t_time. Bene, t_time è una variabile a 32 bit in cui viene memorizzato il numero di secondi a partire dal 1 gennaio 1970 alle ore 12:00:00. Una variabile a 32 bit usa il primo di questi per il segno, i restanti 31 bit invece vengono utilizzati per rappresentare il numero, ciò sta a significare che il numero più grande che t_time può rappresentare è 2 elevato alla 31, cioè 2147483647 (in effetti 2 elevato alla 31 fa  2147483648, ma dobbiamo togliere lo 0!). Quindi se facciamo 2 conti 2147483647 secondi a partire dal  1 gennaio 1970 equivale al 19 gennaio 2038 ore 03:14:07; e dopo? Che succede? Succede che la variabile t_time tornerà al suo massimo valore negativo, cioè -2147483647, che corrisponde a dicembre del 1901!. Questo inconveniente potrebbe provocare blocchi del computer o il semplice cambio della data che ritornerebbe al 1901, ma essendo i sistemi Unix utilizzati in ambiti abbastanza critici, la situazione non è tanto piacevole.

Le soluzioni sono molteplici, si potrebbe trasformare la variabile time_t da 32 a 64 bit, ma fino al 2038 abbiamo ancora un po’ di tempo per pensarci, inoltre John Titor che è tornato indietro nel tempo a posta, potrebbe aver già risolto il problema.