Mille non più Mille

[GuidoB]

Tutto deriva dal fatto che "qualcuno" ha scelto come momento "zero" il 1º gennaio 1970 e ci sono solo 32 bit per contare i secondi da quella data in verso positivo o negativo.

Se quel "qualcuno" avesse scelto il 1º gennaio 2032 saremmo potuti andare indietro fino al 1964 e avanti allegramente fino al 2100, lasciando il problemino ai nostri posteri.

Per le macchine grosse non c'è problema, sono ormai tutte a 64 bit (si potrebbe andare indietro fino al Big Bang e anche prima se c'è un prima... e avanti... fin quasi all'eternità), ma per le macchine piccole... qualcuna sarà ancora in giro dimenticata da tutti, pronta a farsi sentire il giorno fatidico...

Io nel 2038 spero di esserci ancora ma non certo per correre a sistemare bug...

[GuidoB]

Eehhh già...

[GuidoB]

Non so perché questo vecchio thread che ho ritrovato casualmente è "monco", cioè mancano interventi che sono andati perduti, forse cancellati intenzionalmene o forse no.

Comunque già che sono qui aggiungo che il problema dell'anno 2038 (Y2K38 o "epochalypse", come l'ha chiamato qualche informatico burlone) è prevenibile in vari modi.

Quello probabilmente più semplice e leggero su una macchina a 32 bit, che avevo applicato per conservare il valore numerico massimizzando per quanto possibile la compatibilità, è modificare tipi e librerie per utilizzare un intero senza segno (uint32_t) anziché un intero con segno.
In questo modo, rinunciando ai numeri negativi, si rinuncia a rappresentare momenti precedenti al 1º gennaio 1970, ma l'"epochalypse" è rimandata dal 2038 al 2106.
Per allora si spera che non ci siano più macchine attuali a 32 bit in servizio.

Il precedente bug più importante di questo tipo fu il millennium bug, legato alla rappresentazione degli anni con le sole ultime due cifre, che avrebbe dato problemi al passare dal 1999 al 2000.
Fu investito molto per correggere i software in tempo. Comunque tante multinazionali mandarono anche team specializzati in Australia, perché lì l'anno nuovo arriva prima per via del fuso orario, e in caso di problemi che fossero sfuggiti c'era qualche ora di margine per diagnosticarli e risolverli per il resto del mondo.
Alla fine qualche problema imprevisto ci fu, ma non di grande importanza.

Ah, mi ricordo una barzelletta che circolava nel 1999.

Dio convoca Bill Clinton, Boris Yeltsin e Bill Gates:
"Ho convocato voi tre: i presidenti delle più grandi superpotenze e l'uomo più ricco del mondo, per comunicarvi che mi avete stufato. Prima che termini quest'anno, distruggerò il vostro mondo".

Boris Yeltsin riunisce la Duma russa e comunica:
"Ho due pessime notizie. La prima è che Dio esiste, e la seconda è che ha deciso di distruggere il mondo."

Bill Clinton riunisce il Congresso USA e dice:
"Ho due notizie da comunicarvi, una buona e una cattiva. Quella buona è che Dio esiste, quella cattiva è che ha deciso di distruggere il mondo."

Bill Gates riunisce il management della Microsoft e comunica:
"Ho due ottime notizie! È confermato che sono l'uomo più ricco del modo, e Dio ha promesso di risolverci il problema dell'anno 2000!"

[boiler]

Quello probabilmente più semplice e leggero su una macchina a 32 bit, che avevo applicato per conservare il valore numerico massimizzando per quanto possibile la compatibilità, è modificare tipi e librerie per utilizzare un intero senza segno (uint32_t) anziché un intero con segno.

Attenzione perché questa soluzione è sconsigliata. Si può adottare in un sistema chiuso, sul quale si ha completo controllo, sapendo che si perde la compatibilità con librerie esterne e interfacce.

La definizione ufficiale dello unix time, contenuta nello standard POSIX richiede esplicitamente che il tempo sia un signed integer o un float.
--> https://pubs.opengroup.org/onlinepubs/0 ... /time.html
e per la definitione di time_t
--> https://pubs.opengroup.org/onlinepubs/0 ... pes.h.html

Boiler