我读到过有关 NTP 的 2036 问题，因此决定对其进行一些测试。我的服务器从其本地时钟获取时间，而我的客户端仅从此服务器获取时间（甚至不是从其本地时钟获取时间）。
我把服务器日期改为01 JAN 2040 12:00:00，客户端轮询服务器，并将日期改为 2040。我在客户端上运行 NTP 版本 4，这个问题解决了吗？如果是，是在版本 4 还是更早版本？
之后，我决定将服务器日期改为 2070 年。现在客户端忽略了服务器，它可以看到它，轮询达到 377，已经过去了 5 分钟多，但它从未与它同步。看来他因为日期错误而忽略了它。
您知道在客户端忽略之前服务器可以广播的最大日期吗？
答案1
我将其简化了很多，因此那些有兴趣深入了解的人应该阅读相关的 RFC、其他文档和有关该主题的网页。
NTP 无法正确同步到相差超过 68 年的源。NTP 使用 64 位时间戳，其零值为 1900 年 1 月 1 日，但在有线协议上，它被截断为 32 位。未通过网络发送的高 32 位是NTP 时代，时间约为 136 年。NTP 时代 0 从 1900 年 1 月 1 日开始，到 2036 年 2 月 7 日结束，此时 32 位值从 4294967295 翻转为 0，NTP 时代 1 开始。由于 NTP 时代不通过线路发送，因此 NTP 客户端将假定源应在其自身时钟的 2147483648 秒（约 68 年）内。如果差异超过68年，客户端将设置错误的时间或拒绝同步。
当 NTP 时代在 2036 年到来时，这不太可能成为一个实际问题，因为大多数系统的时钟已经设置为 68 年内的值，但当 32 位 UNIX 操作系统的时钟从 2038 年滚动到 1901 年时，这可能是一个更大的问题。它们不仅不再与 NTP 同步，而且当它们运行的任何应用程序由于日期无效而出现故障时，它们还会引发 Y2K 式的混乱。
最终，您的客户端应该会同步 49 年的错误日期，但如果 NTP 客户端只是延迟，您和您认识的每个人都会在同步之前死去。没有人愿意等待 98,000 年才能同步他们的时钟，这就是为什么要逐步调整较大的差异。请注意，如果时钟远远不同步，ntpd 可能会等待 15 分钟才能调整它。你说你只等了五分钟。NTP 客户端或操作系统中可能还发生了其他不太有趣的事情，因为实际上我们只需手动设置时钟并继续我们的一天。