处理 Y2.036K 和 Y2.036K Y2.038K 错误
我目前正在进行一个项目，要求我们的软件必须至少运行到 2050 年。最近，我们在处理 NTP 协议中的 Y2.036K“错误”以及 Y2.038K 错误时遇到了问题。基本上，我们的软件必须在这些日期之后继续运行，并使用正确的时间戳记录所有数据。鉴于目前还没有针对这两个错误的解决方案，必须采用解决方法。
我们的软件在这两个事件发生后保持运行并正确记录日期至关重要。操作系统时间是否正确并不重要。鉴于我们使用的是 Java，我们应该能够处理相对于 1900 年黄金纪元翻转后的日期。然而，如果系统时间设置在 1970 年 Unix 纪元之前，java JVM 甚至不会运行！它只是崩溃了。
火上浇油的是，NTP 服务器是由其他供应商提供的，我们无法控制它。因此，使用其他协议或修改服务器来处理其中任何一个都是不可能的。
需要一个创造性的解决方案。不用说，一定会发生一些深刻的巫术。我们考虑了以下内容：
修改 ntpd 客户端软件，以某种方式与 ntp 服务器协作，并将本地时间从大于 Unix 纪元的 1970 年而不是 1900 年的日期偏移。从而允许 JVM 运行而不会崩溃初始化。所有时间戳将根据我们选择的展期日期进行处理。 （所以基本上，确保我们翻转到大于 Unix 纪元的日期）。
允许 ntp 更正时间翻转到 1900 纪元并找到修复程序，以便 JVM 不会崩溃。
允许 ntp
还有其他人解决过这个问题吗？另外，是否还有其他我没有预见到的问题，导致这些解决方案中的一个或两个根本不可行？
I am currently working on a project with a requirement that our software must operate until at least 2050. Recently we have run into problems dealing with the Y2.036K "bug" in the NTP protocol and also the Y2.038K bug. Basically, our software must continue to run past these dates with all data recorded using correct time stamps. Given that there is currently no solution to either of these bugs a workaround must be employed.
It is critical that our software keeps running after these two events and records dates correctly. It is not critical that the OS system time be correct. Given that we are using Java we should be able to handle dates relative to the prime epoch of 1900 after it rolls over. However, the java JVM will not even run if the system time is set before Unix epoch in 1970! It just crashes.
To add fuel to the fire, the NTP server is supplied by another vendor and we have no control over it. So using another protocol or modifying the server to handle any of this is not possible.
A creative solution is required. Needless to say, some deep voodoo must take place. We have considered the following:
Modify the ntpd client software to somehow co-operate with the ntp server and offset the local time from a date greater than Unix epoch in 1970 rather than 1900. Thus allowing the JVM to run without crashing on initialization. All time stamps will then be handled relative to our chosen rollover date. (So basically, make sure we rollover to a date greater than the Unix epoch).
Allow the ntp corrected time to rollover to 1900 epoch and find a fix so that the JVM will not crash.
Has anyone else tackled this issue? And also, are there any other issues that may occur which I have not foreseen, making one or both of these solutions not feasible at all?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
在具有 64 位 JVM 的 64 位 Linux 上安装软件。
time_t和朋友们这里都是 64 位，将时间调整到 2038 年之后，看看东西是否仍然有效。如果你足够好，扔掉 NTP，找到一个 GPS 或其他可以用作精确时钟并保证它们没有 32 位问题的源，连接你的软件以从中读取/同步时间。Install your software on a 64 bit Linux with a 64 bit JVM.
time_tand friends are 64 bit here, adjust the time past 2038 see if stuff still works. If you're good, toss away NTP, find a gps or other source which can be used as a precise clock and guarantees they don't have 32 bit problems, interface your software to read/sync time from that.