Manuseio de bugs y2.036k e y2.038k

Question

Atualmente, estou trabalhando em um projeto com o requisito de que nosso software opere até pelo menos 2050. Recentemente, tenhamos problemas para lidar com o Y2.036K "Bug" no protocolo NTP e também o Y2.038K Bug. Basicamente, nosso software deve continuar passando por essas datas com todos os dados gravados usando carimbos de hora corretos. Dado que atualmente não há solução para nenhum desses bugs, uma solução alternativa deve ser empregada.

É fundamental que nosso software continue em execução após esses dois eventos e registros datas corretamente. Não é fundamental que o tempo do sistema do sistema operacional esteja correto. Dado que estamos usando o Java, devemos ser capazes de lidar com datas em relação à época principal de 1900, depois que ela rolar. No entanto, a Java JVM nem sequer funcionará se o tempo do sistema for definido antes da Epoch Unix em 1970! Apenas trava.

Para adicionar combustível ao incêndio, o servidor NTP é fornecido por outro fornecedor e não temos controle sobre ele. Portanto, usar outro protocolo ou modificar o servidor para lidar com isso não é possível.

É necessária uma solução criativa. Escusado será dizer que um pouco de vodu profundo deve ocorrer. Nós consideramos o seguinte:

1. Modifique o software do cliente NTPD para de alguma forma cooperar com o servidor NTP e compensar o horário local a partir de uma data maior que a Epoch Unix em 1970, em vez de 1900. permitindo que a JVM funcione sem travar a inicialização. Todos os carimbos de hora serão tratados em relação à data de rolagem escolhida. (Então, basicamente, certifique -se de que rolamos para uma data maior que a época do UNIX).

2. Permita que o NTP corrigiu o tempo para cair para a época de 1900 e encontre uma correção para que a JVM não trave.

Alguém mais abordou esse problema? E também, existem outros problemas que podem ocorrer que eu não prevê, tornando uma ou ambas as soluções não viáveis?

Answer 1

Instale seu software em um Linux de 64 bits com uma JVM de 64 bits. time_t E os amigos têm 64 bits aqui, ajuste o tempo passado 2038, veja se as coisas ainda funcionam. Se você for bom, jogue fora o NTP, encontre um GPS ou outra fonte que possa ser usada como um relógio preciso e garante que eles não tenham problemas de 32 bits, interace seu software para ler/sincronizar o tempo a partir disso.