버그 처리 Y2.036K 및 Y2.038K

Question

저는 현재 2050 년까지 소프트웨어가 작동해야한다는 요구 사항으로 프로젝트를 진행하고 있습니다. 최근에 NTP에서 Y2.036K "버그"를 다루는 문제가 발생했습니다. 프로토콜과 Y2.038K 버그가 있습니다. 기본적으로, 우리의 소프트웨어는 정확한 날짜를 사용하여 기록 된 모든 데이터를 가지고이 날짜를 계속 지나쳐야합니다. 현재이 버그 중 하나에 대한 해결책이 없으므로 해결 방법을 사용해야합니다.

우리의 소프트웨어는이 두 가지 이벤트와 기록이 정확하게 실행 된 후에도 계속 실행되는 것이 중요합니다. OS 시스템 시간이 정확해야한다는 것은 중요하지 않습니다. 우리가 자바를 사용하고 있다면, 롤오버 된 1900 년의 주요 시대에 상대적인 날짜를 처리 할 수 ​​있어야합니다. 그러나 1970 년 유닉스 시대 이전에 시스템 시간을 설정하면 Java JVM이 실행되지 않습니다! 그냥 충돌합니다.

화재에 연료를 추가하려면 NTP 서버가 다른 공급 업체에 의해 공급되며 우리는이를 제어 할 수 없습니다. 따라서 다른 프로토콜을 사용하거나이 중 하나를 처리하기 위해 서버를 수정하는 것은 불가능합니다.

창조적 인 솔루션이 필요합니다. 말할 필요도없이, 깊은 부두교가 일어나야합니다. 우리는 간주 한 다음

1. 따라서에 JVM을 허용 1970보다는 1900 년에 유닉스 시대보다 날로부터 큰 어떻게 든 NTP 서버와 공동 운영하는 ntpd가 클라이언트 소프트웨어를 수정하고 현지 시간 오프셋 초기화시 충돌없이 실행됩니다. 모든 타임 스탬프는 선택한 롤오버 날짜와 관련하여 처리됩니다. (따라서 기본적으로 Unix 시대보다 더 큰 날짜로 ​​롤오버해야합니다.)

2. ntp 수정 시간이 1900 epoch로 롤오버되도록 허용하고 JVM이 충돌하지 않도록 수정 사항을 찾으십시오.

누구든지이 문제를 해결했습니다. 또한 내가 예상하지 못했던 다른 문제가있어이 솔루션 중 하나 또는 둘 다를 실현 불가능하게 만들 수 있습니까?

Answer 1

소프트웨어를 64 비트 JVM이있는 64 비트 Linux에 설치하십시오. time_t 친구들이 여기 64 비트라면, 2038 년 이후의 시간을 조정하여 물건이 여전히 작동하는지 확인하십시오. 니가 훌륭하다면 NTP를 버리고 정확한 시계로 사용할 수있는 GPS 또는 기타 소스를 찾아서 32 비트 문제가 없도록 보장하고, 소프트웨어와 인터페이스하여 시간을 읽고 동기화 할 수 있습니다.