Linux NTPv4标准：实现一个NTP服务器，以检查ntpdate实用程序是否处理2036滚动问题

我想检查NTP的“ntpdate”实用程序是否处理2036年的滚动问题。为此，我想实现一个NTP服务器，它在滚动时间之后生成一个静态时间戳：2036-02-07/06:28:15

我目前正在理解NTP是如何解决这个问题的。我看到协议确实使用64位时间戳（32位秒，32位usec（分数）），我还看到在中定义的新NTPv4标准通过定义三种不同的数据类型来解决这个问题

有三种NTP时间格式，一种是128位的日期格式，一种是64位的 时间戳格式和32位短格式

但在中定义的“数据包头格式”中，使用的时间戳仅保留64位时间戳格式。文件中没有提及如何合并“128位日期格式”，其中包括为解决滚动问题而定义的“era”和“era偏移”数据

“ntpdate”实用程序声称它支持NTPv4标准，所以我猜它也应该支持128位时间戳。我还浏览了的源代码，查看是否支持“era”或“128位时间戳”格式，但我找不到任何指针表明“ntpdate”可以处理128位时间戳

据我所知，NTP是在NTPv4协议中引入的，这是一种128位的日期格式，应该用来解决滚动问题。我的理解正确吗？是否有其他开源服务器可以在线调查2036年过渡问题的“ntpdate”或“ntpd”实用程序的行为

---

提前谢谢

经过大量的研究，我终于得出了这个结论，这个问题已经解释清楚了

事实证明，我们总是可以发送64位格式的时间戳，而不必担心era的时间戳。在本文中，解释了如何从原始历元时间确定时间戳

将任何格式的系统时间转换为NTP日期和时间戳 格式要求从原始历元到 系统时间无法确定。要确定整数纪元和 给定的时间戳

era=s/2^（32）和timestamp=s-era*2^（32）

以上链接中的示例对此进行了说明。我仍然想知道NTPv4为什么要费心定义“128位日期格式”以及它的确切使用位置，但这不是这个问题的范围

此外，此处要添加的可能限制是：这些计算仅适用于邻近的时代，并且仅当客户端由于签名arthematic而设置在服务器的68年内时才有效。引用

事实上，如果客户机设置在协议生效之前服务器的68年内 启动后，即使客户端和服务器 在相邻的时代

谢谢大家!