operating-system - NTP Y2038 & Y2036

Question

我目前正在调查 2036 年和 2038 年翻转错误对特定项目的影响。该项目实施的软件必须能够在这两个日期之后运行。

我最初的研究表明，2036 年的 NTP 时间戳翻转实际上不是问题，因为协议支持。

如果在 64 位操作系统上运行的 NTP 客户端正在同步到在 32 位操作系统上运行的 NTP 服务器，我当前的问题与 2038 翻转条件有关。有谁知道这种情况下64位系统会不会同步不正确？请记住，NTP 协议使用模算术和相对 NTP 时间戳来计算同步偏移量。

Answer 1

首先，即使到明年，任何 32 位机器都不太可能在嵌入式领域之外销售，这意味着当时此类机器的历史将超过 25 年（不太可能，但并非闻所未闻）。

其次，出于时间目的，更好的 32 位操作系统已经部分或全部切换到 64 位，甚至只是一个额外的标志字段来处理时代。因此，运行的操作系统也会同样老旧，这不太可能。

第三，这样一台损坏的机器上的 NTP 服务器（请记住 NTP 时间戳不仅仅是操作系统时间戳）很可能会处理这个问题。

第四，如果不同步，您可能无法同步，如果同步，您也不想同步。

Answer 2

AFAIK，否--NTP 可以处理那些 2036/2038 日期和 32 位与 64 位机器。

但是，顺便说一句，观看时间是：2004 年 1 月 10 日星期六 13:37:04 GMT+0000（1970 年 1 月 1 日 00:00:00 + 0x3ffffffff 秒）。如果客户端到服务器的时间差 > 0x3ffffffff 秒（约 34 年），并且没有“伙伴时代”，那么 NTP 可能不会同步。请参阅 Mills 博士的“计算机网络时间同步：网络时间协议”中的第 9 页和第 216 页：“34 年的限制是非常真实的，如 2004 年初的 NTP 超过了 unix 时钟的时代”......“为了符合正确性原则，需要在协议启动前将系统时钟设置在当前 UTC 时间的 34 年内。” 我遇到过在 RTC 电池没电时重新启动后在生产中遇到此问题的系统（出现于 1970 年 1 月 1 日星期四格林威治标准时间 00:00:00）。