Gestione Y2.036K & Y2.038K bug

Question

Attualmente sto lavorando su un progetto con un requisito che il nostro software deve funzionare almeno fino al 2050. Recentemente abbiamo incorrere in problemi riguardanti la "bug" Y2.036K nel protocollo NTP e anche il bug Y2.038K. In sostanza, il nostro software deve continuare a correre oltre queste date con tutti i dati registrati utilizzando corretti timestamp. Dato che non esiste attualmente alcuna soluzione a uno di questi insetti una soluzione alternativa deve essere impiegato.

E 'fondamentale che il nostro software continua a funzionare dopo questi due eventi e record date in modo corretto. Non è fondamentale che il tempo del sistema operativo sia corretto. Dato che stiamo usando Java dovremmo essere in grado di gestire le date relative all'epoca primo del 1900 dopo che rotola. Tuttavia, il Java JVM non viene eseguito neppure se l'ora di sistema è impostato prima dell'epoca Unix nel 1970! Si blocca solo.

Per aggiungere benzina sul fuoco, il server NTP è fornito da un altro fornitore e non abbiamo alcun controllo su di esso. Quindi, utilizzando un altro protocollo o modificare il server per gestire tutto questo non è possibile.

è necessaria una soluzione creativa. Inutile dire che, un po 'voodoo profonda deve avvenire. Abbiamo considerato il seguente:

1. Modifica il software client ntpd in qualche modo co-operare con il server NTP e l'offset l'ora locale da una data maggiore di epoca Unix nel 1970 invece che 1900. Permettendo così la JVM per l'esecuzione senza schiantarsi su di inizializzazione. Tutte le marche temporali saranno poi trattati relativi alla nostra data di rollover prescelto. (Quindi, fondamentalmente, essere sicuri di rollover a una data superiore dell'epoca Unix).

2. Lasciare che il ntp corretto tempo di rollover per l'epoca 1900 e trovare una soluzione in modo che la JVM non vada in crash.

Qualcun altro ha affrontato questo problema? E inoltre, ci sono altri problemi che possono verificarsi che non ho previsto, rendendo una o entrambe queste soluzioni non praticabili a tutti?

Answer 1

Installare il software su un 64 bit di Linux con un 64 bit JVM. time_t e gli amici sono qui a 64 bit, regolare il tempo passato, 2038 vedere se funziona ancora roba. Se sei bravo, buttare via NTP, trovare un GPS o di altra fonte che può essere utilizzato come un orologio preciso e garantisce di non avere problemi di 32 bit, interfacciare il software per leggere / tempo di sincronizzazione da questo.