Il bug dell'anno 2038 è un noto bug informatico che ha ripercussioni su alcuni software nella gestione di date relative all'anno 2038 e successivi.

Il problema riguarda programmi che usano la rappresentazione POSIX per calcolare il tempo: questa calcola la data del sistema come il numero di secondi trascorsi dallo Unix Epoch Time 1º gennaio 1970 (ignorando i secondi intercalari). 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 è martedì 19 gennaio 2038 alle ore 03:14:07 UTC. 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 UTC di venerdì 13 dicembre 1901), causando errori di calcolo[1]. "Year 2038" è chiamato anche "Y2038", "Y2K38", o "Y2.038K" nel linguaggio specialistico.

FONTE:WIKIPEDIA


In parole povere, quelli che hanno "progettato" il modo di contare il tempo (cioè contando dal 1/1/1970 ogni secondo trascorso), non hanno pensato che qualcuno potesse vivere fino al 19/01/2038, quando questo numero sarà troppo grande e i computer, al secondo successivo, ricominceranno il conto da capo...

Questa è un'utile rappresentazione della realtà!

tutto molto vero...penso anche pero' che non si poteva fare al tempo qualcosa di meglio,e sono convinto che entro gia' il 2030 i sistemi operativi a 32 bit non saranno nemmeno piu' sviluppati e andra' per la maggiore il 64 bit,mentre sara' in procinto di sviluppo il 128...
e cosi via...

e mò come facciamo?? D:
ma non si può allungare questo numero? D:

O.G.M ha scritto:

tutto molto vero...penso anche pero' che non si poteva fare al tempo qualcosa di meglio,e sono convinto che entro gia' il 2030 i sistemi operativi a 32 bit non saranno nemmeno piu' sviluppati e andra' per la maggiore il 64 bit,mentre sara' in procinto di sviluppo il 128...
e cosi via...

Questo può essere vero, ma ci sono banche e grandi database che ad oggi usano ancora cobol perchè non vogliono utilizzare tecnologie più nuove: troppo costoso cambiare una cosa che funziona.
E il problema non è solo del 2038! Ma se (esempio) una banca ad oggi inserisce un mutuo trentennale nei suoi database... va in overflow!
Non lo so sai se sarà un problema di facile soluzione... si tratta di cambiare uno standard infondo... e ancora adesso escono programmi basati sulla time.h... bisogna vedere quando finiranno... e se stanno già lavorando a questa cosa... Oppure se contiamo di chiudere i battenti nel 2012 e quindi...

Better ha scritto:

e mò come facciamo?? D:
ma non si può allungare questo numero? D:

Non si può perchè farlo significherebbe che molti programmi che fino ad oggi si sono aspettati di trovare un numero grande tot, se ne troverebbero uno molto più grande, e non è sicuro che questo cambio nella struttura mantenga la compatibilità con tutti i programmi, anzi...
Inoltre un ipotetico "allungamento" della data può essere implementato solo su macchine con architettura a 64 bit... le 32 non posso comunque leggere un numero più grande di così!