我读到了 NTP 的 2036 问题，我决定对其进行一些测试。我的服务器从他的本地时钟获取时间，而我的客户端仅从该服务器获取时间（甚至不是他的本地时钟）。
我将服务器日期更改为01 JAN 2040 12:00:00，客户端正在轮询服务器并将其日期更改为 2040。我在客户端上运行 NTP 版本 4，此问题是否已修复？如果是，是版本 4 还是更早版本？
之后，我决定将服务器日期更改为 2070 年。现在客户端忽略服务器，它可以看到它，轮询达到 377，已经过去了 5 多分钟，但它从未同步到它。他似乎因为约会错误而忽略了它。
您知道在客户端忽略它之前服务器可以广播的最长时间吗？
我进行了相当多的简化，因此那些有兴趣深入研究的人应该阅读相关的 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 年，客户端要么设置错误的时间，要么拒绝同步。
这不太可能在 2036 年 NTP 时代结束时成为实际问题，因为大多数系统已经将时钟设置为 68 年内的值，但在 2038 年基于 32 位 UNIX 的操作时，这可能是一个更大的问题系统的时钟从 2038 年翻转到 1901 年。它们不仅不再与 NTP 同步，而且当它们运行的任何应用程序由于无效日期而出现异常时，它们将引发 Y2K 式的混乱。
最终，您的客户端错误日期为 49 年应该同步，但如果 NTP 客户端只是旋转，您和您认识的每个人都会在它发生之前很久就死了。没有人愿意等待 98,000 年才能同步他们的时钟，这就是为什么会出现巨大差异的原因。请注意，如果时钟远不同步，ntpd 可能会等待多达 15 分钟，然后再步进。你说你只等了五分钟。NTP 客户端或操作系统中可能还会发生其他不太有趣的事情，因为实际上我们将手动设置时钟并继续我们的一天。