L'orologio Linux fallirà il 19 gennaio 2038 3:14:08?

22

Sono un po 'preoccupato per questo. Si chiama "problema dell'anno 2038". Il kernel Linux o Ubuntu è pronto per gestire le date successive a questo, a partire dal 12.04?

    
posta ThePiercingPrince 24.05.2013 - 14:00
fonte

4 risposte

12

No, non fallirà. Nel peggiore dei casi, dal punto di vista di un programmatore funzionerà come previsto: verrà resettato fino al 1901-12-13 alle 20:45:52:

Nel caso in cui non aggiorni le tue distribuzioni attuali fino a quando ciò non si verifica. " L'aggiornamento è semplice. Uno di questi aggiornamenti conterrà sicuramente una correzione. " come chocobai ha detto .

Ricordo che era lo stesso problema / domanda con macchine a 16 bit prima del 2000 e alla fine non c'erano problemi.

Una soluzione da Wikipedia:

  

La maggior parte dei sistemi operativi progettati per l'esecuzione su hardware a 64 bit utilizzano già interi di time_t firmati a 64 bit. L'utilizzo di un valore a 64 bit con segno introduce una nuova data avvolgente che è oltre venti volte maggiore dell'età stimata dell'universo: circa 292 miliardi di anni da oggi, alle 15:30:08 di domenica 4 dicembre 292.277.026.596. La possibilità di eseguire calcoli sulle date è limitata dal fatto che tm_year utilizza un valore int con 32 bit con segno a partire da 1900 per l'anno. Ciò limita l'anno a un massimo di 2.147.485.547 (2.147.483.647 + 1900). Mentre questo risolve il problema per l'esecuzione di programmi, non risolve il problema di memorizzare i valori di data all'interno di file di dati binari, molti dei quali utilizzano formati di archiviazione rigidi. Inoltre, non risolve il problema per i programmi a 32 bit in esecuzione sotto livelli di compatibilità e potrebbe non risolvere il problema per i programmi che memorizzano in modo errato i valori di tempo in variabili di tipi diversi da time_t .

Uso Ubuntu 13.04 su 64-bit e, per curiosità, ho modificato manualmente l'ora in 2038-01-19 03:13:00. Dopo 03:14:08 non era successo nulla:

Quindi non c'è nulla di cui preoccuparsi per questo problema.

Ulteriori informazioni su:

risposta data Radu Rădeanu 24.05.2013 - 14:45
fonte
7

Puoi controllare se il tempo del tuo computer si blocca usando il seguente script Perl:

#!/usr/bin/perl
use POSIX;
$ENV{'TZ'} = "GMT";
for ($clock = 2147483641; $clock < 2147483651; $clock++) {
    print ctime($clock);
}

Se il tuo computer andrà bene, otterrai questo:

Tue Jan 19 03:14:01 2038
Tue Jan 19 03:14:02 2038
Tue Jan 19 03:14:03 2038
Tue Jan 19 03:14:04 2038
Tue Jan 19 03:14:05 2038
Tue Jan 19 03:14:06 2038
Tue Jan 19 03:14:07 2038       <-- Last second in 32-bit Unix systems
Tue Jan 19 03:14:08 2038
Tue Jan 19 03:14:09 2038
Tue Jan 19 03:14:10 2038

Se il tuo computer è come il mio, si avvolgerà in questo modo:

Tue Jan 19 03:14:01 2038
Tue Jan 19 03:14:02 2038
Tue Jan 19 03:14:03 2038
Tue Jan 19 03:14:04 2038
Tue Jan 19 03:14:05 2038
Tue Jan 19 03:14:06 2038
Tue Jan 19 03:14:07 2038
Fri Dec 13 20:45:52 1901
Fri Dec 13 20:45:52 1901
Fri Dec 13 20:45:52 1901

Potrebbe anche fare questo:

Tue Jan 19 03:14:01 2038
Tue Jan 19 03:14:02 2038
Tue Jan 19 03:14:03 2038
Tue Jan 19 03:14:04 2038
Tue Jan 19 03:14:05 2038
Tue Jan 19 03:14:06 2038
Tue Jan 19 03:14:07 2038
Tue Jan 19 03:14:07 2038
Tue Jan 19 03:14:07 2038
Tue Jan 19 03:14:07 2038
    
risposta data SkylarMT 26.06.2013 - 01:13
fonte
3

Ho scritto e pubblicato un breve articolo su questo nel 1996. Questo comprendeva un breve programma in C per dimostrarlo. Ho anche avuto e-mail con David Mills su problemi simili con NTP - Network Time Protocol. Sul mio computer portatile a 64 bit Ubuntu 14.04 il codice perl non mostrava la limitazione, quindi le librerie a 64 bit sottostanti devono essere state modificate.

Tuttavia, l'esecuzione del mio codice di test di tanto tempo fa mostra il tempo di ritorno a UNIX Epoch. Quindi non tutto va bene con il codice a 32 bit del passato.

Il mio articolo del 1996, Il tempo UNIX si esaurirà nel 2038! è stato sul mio sito web dal 2000 circa. Una variante di questo "UNIX Time" è stata pubblicata nel 1998 in "Anno 2000 Best Practices per Y2K Millennium Computing" ISBN 0136465064.

    
risposta data oldunixguy 21.02.2017 - 00:10
fonte
2

Linux a 64 bit è pronto, almeno se si parla delle interfacce principali del sistema operativo (le singole applicazioni possono ovviamente rovinare tutto). time_t è tradizionalmente definito come un alias per "long" e "long" su 64-bit linux è 64-bit.

La situazione per Linux a 32 bit (e il livello di compatibilità per i binari a 32 bit su Linux a 64 bit) è molto meno rosea. È rotto e risolvendolo senza rompere tutti i binari esistenti non è un compito facile. Un sacco di API utilizzano time_t e in molti casi è incorporato come parte delle strutture di dati, quindi non solo è necessario duplicare le API con le strutture dati con cui devono lavorare.

Anche se esiste un qualche livello di compatibilità con le versioni precedenti, tutti i file binari che vogliono ottenere il tempo corretto dovranno essere ricostruiti per utilizzare le nuove interfacce temporali a 64 bit.

C'è stato un po 'di lavoro (vedi ad esempio link e collegamento ) ma afaict siamo ancora molto lontani da una soluzione completa. Non è chiaro se ci saranno mai distribuzioni a 32 bit per uso generico che sono Y2K38 sicure.

    
risposta data Peter Green 27.04.2016 - 02:09
fonte

Leggi altre domande sui tag