NTP Y2038和Y2036
我目前正在调查2036年和2038年的翻转错误对一个特定项目的影响。此项目实现的软件必须能够在这两个日期之后运行。
我的初步研究表明，2036年的NTP时间戳翻转实际上是没有问题的，因为协议是有效的。
如果运行在64位操作系统上的NTP客户端与运行在32位操作系统上的NTP服务器同步，则我当前的问题与2038转存条件有关。有没有人知道在这种情况下，64位系统是否会不正确地同步？请记住，NTP协议使用模算法和相对NTP时间戳来计算同步偏移。
回答 2
Stack Overflow用户
发布于 2009-12-22 18:31:27
首先，到明年为止，不太可能有任何32位机器在嵌入式领域之外销售，这意味着这样的机器在当时已经有超过四分之一个世纪的历史(不太可能，但并非闻所未闻)。
其次，更好的32位操作系统已经在时间上部分或全部切换到64位，甚至只是一个额外的标志字段来处理纪元，所以运行的操作系统也会同样旧，这是不太可能的。
第三，在这样一台损坏的机器上的NTP服务器(请记住，NTP时间戳不仅仅是操作系统时间戳)可能会处理这个问题。
第四，如果它没有，你可能无法同步到它，如果它做到了，你就不想同步了。
Stack Overflow用户
发布于 2021-08-05 14:52:46
AFAIK，否--NTP可以处理这些2036/2038日期和32 vs 64位机器。
但是，顺便说一句，观看的时间是: Sat Jan 10 2004 13:37:04 GMT+0000 (00:00:00 1970年1月1日+ 0x3ffffffff秒)。如果客户端与服务器的时间差大于0x3ffffffff秒(~34年)，并且没有“伙伴时期”，则NTP可能不会同步。参考Mills博士的"Computer Network Time Synchronization: the Network Time Protocol“中的第9页和216页：”34年的限制是非常真实的，因为在2004年初，NTP超过了unix时钟的年龄“……为符合正确性原则，必须在启动协议之前将系统时钟设置在当前UTC时间的34年内。我遇到过在RTC电池耗尽(出现在清华Jan 01 1970 00:00:00 GMT)时重新启动后在生产中遇到此问题的系统。
https://stackoverflow.com/questions/1502697
复制相似问题
腾讯云开发者
