Manipulación y Y2.036K Y2.038K errores

Question

Actualmente estoy trabajando en un proyecto con el requisito de que nuestro software debe funcionar al menos hasta el año 2050. Recientemente se han topado con problemas relacionados con la Y2.036K "error" en el protocolo NTP y también el fallo Y2.038K. Básicamente, nuestro software debe seguir funcionando más allá de estas fechas con todos los datos grabados utilizando las marcas de tiempo correctos. Dado que actualmente no existe una solución a cualquiera de estos errores se deben emplear una solución.

Es fundamental que nuestro software sigue funcionando después de estos dos eventos y fechas de registros correctamente. No es crítico que la hora del sistema OS sea correcta. Dado que estamos utilizando Java debemos ser capaces de manejar las fechas relativas a la época principal de 1900 después de que se da la vuelta. Sin embargo, la JVM de Java ni siquiera se ejecutarán si la hora del sistema se establece antes de que Unix época en 1970! Sólo se bloquea.

Para añadir más leña al fuego, el servidor NTP es suministrado por otro proveedor y no tenemos ningún control sobre él. Así, utilizando otro protocolo o modificar el servidor para manejar todo esto no es posible.

Se requiere una solución creativa. Ni que decir tiene, vudú profundo debe tener lugar. Hemos considerado lo siguiente:

1. Modificar el software de cliente de alguna manera ntpd cooperar con el servidor NTP y compensar la hora local de una mayor fecha de Unix época en 1970 en lugar de 1900. Por lo tanto permitiendo que la JVM para ejecutar sin que se caiga en la inicialización. Todas las marcas de tiempo serán manejadas en relación con nuestra fecha de prórroga elegido. (Así que, básicamente, asegúrese de que reinversión en una mayor fecha de la época Unix).

2. Permitir la NTP en compensado a volcarse a la época 1900 y encontrar una solución para que la JVM no se bloqueará.

¿Alguien más ha abordado este tema? Y también, ¿hay otros problemas que pueden producirse los que tengo no previstos, por lo que una o ambas de estas soluciones no es factible en absoluto?

Answer 1

Instalar el software en un 64 bits Linux con un 64 bits JVM. time_t y amigos son de 64 bits aquí, ajustar el tiempo pasado 2038 a ver si las cosas aún funciona. Si eres bueno, tirar NTP, encontrar un GPS o de otra fuente que se pueden utilizar como un reloj y garantías precisas que no tienen problemas de 32 bits, la interfaz de su software para leer / tiempo de sincronización de eso.