處理Y2.036K和Y2.038K錯誤

Question

我目前正在開發一個項目，要求我們的軟件必須運行至少2050年。最近我們遇到了處理NTP中Y2.036K「bug」的問題協議和Y2.038K錯誤。基本上，我們的軟件必須繼續運行這些日期，並使用正確的時間戳記錄所有數據。鑑於目前還沒有解決這些錯誤的方法，必須採用一種解決方法。

在這兩個事件並正確記錄日期之後，我們的軟件保持運行至關重要。操作系統系統時間正確無關緊要。鑑於我們正在使用Java，我們應該能夠處理相對於1900年的主要時期的日期。然而，如果系統時間在1970年的UNIX時代之前設置，java JVM甚至不會運行！它只是崩潰。

爲了增加燃料消耗，NTP服務器由另一個供應商提供，我們無法控制它。所以使用其他協議或修改服務器來處理這些是不可能的。

需要創造性的解決方案。不用說，必須發生一些深沉的巫術。我們曾考慮以下幾點：

1. 從日期修改NTPD客戶端軟件以某種方式與NTP服務器協同工作和偏差的本地時間大於Unix紀元1970年，而不是1900年。因此，允許對JVM在初始化時運行時不會崩潰。所有的時間戳將被處理相對於我們選擇的翻轉日期。 （所以基本上，確保我們翻轉到比Unix紀元更大的日期）。

2. 允許ntp更正的時間翻轉到1900時期並找到修復，以便JVM不會崩潰。

有沒有其他人處理過這個問題？還有，我還沒有預見到可能會發生的其他問題，使這些解決方案中的一個或兩個都不可行嗎？

Answer 1

在具有64位JVM的64位Linux上安裝軟件。 time_t和朋友在這裏是64位，調整過去2038年的時間，看看東西是否仍然有效。如果你不錯，拋棄NTP，找到一個可用作精確時鐘的GPS或其他信號源，並確保它們沒有32位問題，通過接口軟件讀取/同步時間。