Manipulation des bugs Y2.036K et Y2.038K

Question

Je travaille actuellement sur un projet avec une exigence que notre logiciel doit fonctionner au moins jusqu'à 2050. Récemment, nous avons rencontré des problèmes relatifs à la Y2.036K « bug » dans le protocole NTP et aussi le bug Y2.038K. En gros, notre logiciel doit continuer à exécuter ces dernières dates avec toutes les données enregistrées en utilisant l'horodatage corrects. Étant donné qu'il n'y a actuellement pas de solution à l'un de ces bogues une solution doit être utilisée.

Il est essentiel que notre logiciel continue à fonctionner après ces dates correctement deux événements et dossiers. Il n'est pas essentiel que le temps du système d'exploitation soit correct. Étant donné que nous utilisons Java, nous devrions être en mesure de traiter les dates par rapport à l'époque premier de 1900 après roule. Cependant, la machine virtuelle Java Java ne fonctionnera pas, même si le temps de système est réglé avant époque Unix en 1970! Il tombe en panne juste.

Pour ajouter du carburant au feu, le serveur NTP est fourni par un autre fournisseur et nous n'avons pas le contrôle. Donc, en utilisant un autre protocole ou de modifier le serveur pour gérer tout cela est impossible.

Une solution créative est nécessaire. Inutile de dire que certains voodoo profonde doit avoir lieu. Nous avons examiné les éléments suivants:

1. Modifier le logiciel client ntpd en quelque sorte à coopérer avec le serveur ntp et le décalage de l'heure locale à une date supérieure à l'époque Unix en 1970 plutôt que 1900. Permettant ainsi à la machine virtuelle Java de fonctionner sans plantage lors de l'initialisation. Tous les horodateurs seront ensuite traitées par rapport à notre date de roulement choisie. (Donc, en gros, assurez-vous que nous capotage à une date supérieure à l'époque Unix).

2. Laisser le temps corrigé ntp au retournement à 1900 époque et trouver une solution pour que la machine virtuelle Java ne plantera pas.

Quelqu'un at-il abordé cette question d'autre? Et aussi, y at-il d'autres problèmes qui peuvent se produire que je ne l'ai pas prévue, ce un ou l'autre de ces solutions pas possible du tout?

Answer 1

Installez votre logiciel sur un 64 bits Linux avec une machine virtuelle Java 64 bits. time_t et les amis sont ici 64 bits, réglez le temps passé 2038 voir si des choses fonctionne toujours. Si vous êtes bon, jeter loin NTP, trouver un GPS ou une autre source qui peut être utilisé comme une horloge précise et garantit qu'ils n'ont pas 32 problèmes de bits, l'interface de votre logiciel de lecture / temps de synchronisation de cela.