Cosa dovremmo fare per prepararci al 2038?

StackOverflow https://stackoverflow.com/questions/36239

Domanda

Mi piace pensare che parte del software che scrivo oggi verrà utilizzato tra 30 anni.Ma sono anche consapevole che gran parte di esso si basa sulla tradizione UNIX di esporre il tempo come numero di secondi a partire dal 1970.

#include <stdio.h>
#include <time.h>
#include <limits.h>

void print(time_t rt) {
    struct tm * t = gmtime(&rt);
    puts(asctime(t));
}

int main() {
    print(0);
    print(time(0));
    print(LONG_MAX);
    print(LONG_MAX+1);
}

L'esecuzione risulta in:

  • Gio 1 gennaio 00:00:00 1970
  • Sabato 30 agosto 18:37:08 2008
  • Mar 19 gennaio 03:14:07 2038
  • Venerdì 13 dicembre 20:45:52 1901

Le funzioni ctime(), gmtime() e localtime() prendono tutte come argomento un valore temporale che rappresenta il tempo in secondi trascorso dall'Epoca (00:00:00 UTC, 1 gennaio 1970;vedi ora(3) ).

Mi chiedo se ci sia qualcosa di proattivo da fare in quest'area come programmatore, o dobbiamo fidarci del fatto che tutti i sistemi software (ovvero i sistemi operativi) verranno in qualche modo magicamente aggiornati in futuro?

Aggiornamento Sembrerebbe che in effetti i sistemi a 64 bit siano al sicuro da questo:

import java.util.*;

class TimeTest {
    public static void main(String[] args) {
        print(0);
        print(System.currentTimeMillis());
        print(Long.MAX_VALUE);
        print(Long.MAX_VALUE + 1);
    }

    static void print(long l) {
        System.out.println(new Date(l));
    }
}
  • Mercoledì 31 dicembre 16:00:00 PST 1969
  • Sabato 30 agosto 12:02:40 PDT 2008
  • Sabato 16 agosto 23:12:55 PST 292278994
  • Dom 2 dic 08:47:04 PST 292269055

Ma che dire dell'anno 292278994?

È stato utile?

Soluzione

Ho scritto un sostituto portatile per time.h (attualmente solo localtime(), gmtime(), mktime() e timegm()) che utilizza il tempo a 64 bit anche su macchine a 32 bit.È destinato a essere inserito nei progetti C in sostituzione di time.h.Viene utilizzato in Perl e intendo risolvere anche i problemi 2038 di Ruby e Python.Questo ti dà un intervallo sicuro di +/- 292 milioni di anni.

Puoi trovare il codice al progetto y2038.Non esitate a postare eventuali domande al tracker dei problemi.

Per quanto riguarda "questo non sarà un problema per altri 29 anni", leggi attentamente questo elenco di risposte standard a tale.In breve, le cose accadono in futuro e talvolta è necessario sapere quando.Ho anche una presentazione sul problema, cosa non è una soluzione e cosa lo è.

Oh, e non dimenticare che molti sistemi temporali non gestiscono le date precedenti al 1970.Le cose sono accadute prima del 1970, a volte bisogna sapere quando.

Altri suggerimenti

Puoi sempre implementare RFC2550 e sarai al sicuro per sempre ;-)

L'universo conosciuto ha un passato e un futuro finiti.L'attuale età dell'universo è stimata in [Zebu] tra 10 ** 10 e 2 * 10 ** 10 anni.La morte dell'universo è stimata in [Nigel] che si verifichi in 10 ** 11 anni e in [Drake] come si verifica in 10 ** 12 anni per un universo chiuso (la grande scricchiolio) o 10 ** 14 anni per un universo aperto (la morte di calore dell'universo).

 

I programmi conformi a Y10K possono scegliere di limitare la gamma di date che supportano a quelle coerenti con la vita prevista dell'universo.I sistemi conformi a Y10K devono accettare le date Y10K da 10 ** 12 anni negli ultimi 10 ** 20 anni nel futuro.I sistemi conformi a Y10K dovrebbero accettare date per almeno 10 ** 29 anni in passato e futuro.

Visual Studio è passato a una rappresentazione a 64 bit di time_t in Visual Studio 2005 (pur lasciando _time32_t per compatibilità con le versioni precedenti).

Finché stai attento a scrivere sempre il codice in termini di time_t e non dare per scontato nulla sulla dimensione, come sottolinea sysrqb il problema verrà risolto dal tuo compilatore.

Penso che dovremmo lasciare dentro il bug.Poi verso il 2036 potremo iniziare a vendere consulenze per ingenti somme di denaro per testare tutto.Dopo tutto, non è così che abbiamo gestito con successo il passaggio dal 1999 al 2000.

Sto solo scherzando!

Ero seduto in una banca a Londra nel 1999 e sono rimasto piuttosto stupito quando ho visto un consulente iniziare il test Y2K della macchina da caffè.Penso che se abbiamo imparato qualcosa da quel fiasco, è che la stragrande maggioranza dei software funzionerà e la maggior parte del resto non causerà un crollo in caso di guasto e potrà essere riparato dopo l'evento, se necessario.Pertanto, non prenderei alcuna precauzione speciale fino a quando non si avvicinasse il momento.

Data la mia età, penso che dovrei versare molto nella mia pensione e pagare tutti i miei debiti, quindi qualcun altro dovrà installare il software!

Siamo spiacenti, se pensi al “valore attuale netto” di qualsiasi software che scrivi oggi, non ha alcun effetto su ciò che farà il software nel 2038.Un "ritorno sull'investimento" di più di qualche anno è raro per qualsiasi progetto software, quindi guadagni molto più denaro per il tuo datore di lavoro facendo spedire il software più rapidamente, invece di pensare così in anticipo.

L’unica eccezione comune è il software che deve prevedere il futuro, il 2038 è già un problema per i sistemi di quotazione dei mutui.

Conserva una buona documentazione e includi una descrizione delle tue dipendenze temporali.Non penso che molte persone abbiano pensato a quanto potrebbe essere difficile questa transizione, ad esempio i cookie HTTP si interromperanno in quella data.

Cosa dovremmo fare per prepararci al 2038?

Nasconditi, perché l'apocalisse sta arrivando.

Ma seriamente, spero che i compilatori (o le persone che li scrivono, per essere precisi) possano gestirlo.Hanno quasi 30 anni.Spero che sia abbastanza tempo.

A che punto inizieremo a prepararci per Y10K?Qualche produttore di hardware/laboratorio di ricerca ha esaminato il modo più semplice per passare a qualunque nuova tecnologia dovremo avere a causa di ciò?

Lavoro in embedded e ho pensato di pubblicare la nostra soluzione qui.I nostri sistemi sono a 32 bit e ciò che vendiamo in questo momento ha una garanzia di 30 anni, il che significa che incontreranno il bug dell'anno 2038.L'aggiornamento in futuro non era una soluzione.

Per risolvere questo problema, impostiamo la data del kernel 28 anni prima rispetto alla data attuale.Non è uno spostamento casuale, 28 anni è esattamente il tempo necessario affinché i giorni della settimana corrispondano nuovamente.Ad esempio, sto scrivendo questo giovedì e la prossima volta che il 7 marzo sarà un giovedì sarà tra 28 anni.

Inoltre, tutte le applicazioni che interagiscono con le date sui nostri sistemi prenderanno la data di sistema (time_t) la convertiranno in un'ora personalizzata64_t e applicheranno l'offset di 28 anni alla data giusta.

Abbiamo creato una libreria personalizzata per gestire questo.Il codice che stiamo utilizzando si basa su questo: https://github.com/android/platform_bionic

Quindi, con questa soluzione puoi comprarti facilmente 28 anni in più.

Entro il 2038, tutte le librerie temporali dovrebbero utilizzare numeri interi a 64 bit, quindi questo non sarà un grosso problema (su software che non è completamente privo di manutenzione).

I programmi COBOL potrebbero essere divertenti però.

La parola operativa è "dovrebbe".

Se hai bisogno di garantire la prova a prova di futuro, puoi costruire la tua classe di data/ora e usarla, ma lo farei solo se ritieni che ciò che scrivi verrà utilizzato su sistemi operativi legacy

Autorizzato sotto: CC-BY-SA insieme a attribuzione
Non affiliato a StackOverflow
scroll top