我目前正在开发一个项目，要求我们的软件必须至少运行到 2050 年。最近，我们在处理 NTP 协议(protocol)中的 Y2.036K“bug”以及 Y2.038K bug 时遇到了问题。基本上，我们的软件必须在这些日期之后继续运行，并使用正确的时间戳记录所有数据。鉴于目前还没有针对这两个错误的解决方案，必须采用解决方法。
我们的软件在这两个事件发生后保持运行并正确记录日期至关重要。操作系统时间是否正确并不重要。鉴于我们使用的是 Java，我们应该能够处理相对于 1900 年黄金纪元翻转后的日期。然而，如果系统时间设置在 1970 年 Unix 纪元之前，java JVM 甚至不会运行!它只是崩溃了。
火上浇油的是，NTP 服务器由另一家供应商提供，我们无法控制它。因此，使用其他协议(protocol)或修改服务器来处理任何这些都是不可能的。
需要一个创造性的解决方案。不用说，一定会发生一些深刻的巫术。我们考虑了以下几点:
修改 ntpd 客户端软件以某种方式与 ntp 服务器协作，并将本地时间从 1970 年(而不是 1900 年)大于 Unix 纪元的日期偏移。从而允许 JVM 运行而不会在初始化时崩溃。所有时间戳将根据我们选择的展期日期进行处理。 (所以基本上，确保我们滚动到大于 Unix 纪元的日期)。
允许 ntp 更正时间滚动到 1900 纪元并找到修复程序，以便 JVM 不会崩溃。
还有其他人解决过这个问题吗？另外，是否还有其他我没有预见到的问题，导致这些解决方案中的一个或两个根本不可行？
最佳答案
在具有 64 位 JVM 的 64 位 Linux 上安装您的软件。 time_t 和 friend 们这里都是 64 位，将时间调整到 2038 年之后，看看东西是否仍然有效。如果你足够好，扔掉 NTP，找到一个 GPS 或其他可以用作精确时钟并保证它们没有 32 位问题的源，连接你的软件以从中读取/同步时间。
关于ntp - 处理 Y2.036K 和 Y2.038K 错误，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/1399834/