NTPv4 标准：实施 NTP 服务器以检查 ntpdate 实用程序是否处理 2036 翻转问题
NTPv4 standard: Implement an NTP server to check if ntpdate utility handles the 2036 rollover issue
我想检查 NTP 的“ntpdate”实用程序是否处理 2036 翻转问题。为此，我想实现一个 NTP 服务器，它在翻转时间后生成一个静态时间戳：2036-02-07/06:28:15.
我目前还停留在理解 NTP 如何解决这个问题上。我看到 NTPv3 protocol does use 64-bit timestamps (32-bit seconds, 32-bit usec(fraction)) and I also see that new NTPv4 standard defined in rfc5905 page12 通过定义三种不同的数据类型解决了这个问题。
There are three NTP time formats, a 128-bit date format, a 64-bit
timestamp format, and a 32-bit short format
但是在page 18中定义的“包头格式”中，使用的时间戳只包含64位时间戳格式。文档中没有其他地方提到我们如何合并“128 位日期格式”，其中包括为解决翻转问题而定义的“纪元”和“纪元偏移”数据。
“ntpdate”实用程序声称它支持 NTPv4 标准，所以我猜它也应该支持 128 位时间戳。我还查看了 ntpdate 的源代码，看看是否支持“时代”或“128 位时间戳”格式，但我找不到任何指示 'ntpdate' 可以处理的指针128 位时间戳。
据我了解，NTP在NTPv4协议中引入了一种128位的日期格式，应该用来解决翻转问题。我的理解正确吗？是否有任何其他在线开源服务器可用于调查 'ntpdate' 或 'ntpd' 实用程序针对 2036 年翻转问题的行为？
提前致谢！
经过大量研究，我想出了这个 link，问题解释得很清楚。
事实证明，我们总是可以只发送定义的 64 位格式的时间戳，而不用担心时代的问题。 Charpter 6 of rfc5905中解释了如何从Prime-epoch时间确定时间戳。
To convert system time in any format to NTP date and timestamp
formats requires that the number of seconds s from the prime epoch to
the system time be determined. To determine the integer era and
timestamp given s,
era = s / 2^(32) and timestamp = s - era * 2^(32)
同上link中的例子进行了说明。我仍然想知道为什么 NTPv4 费心去定义“128 位日期格式”以及它究竟用在哪里，但这不是这个问题的范围。
这里可能要添加的限制是：这些计算只适用于相邻的时代，并且只有当客户端设置在服务器的 68 年内，因为签名的艺术。引用自 Section 6, Page 5
In point of fact, if the client is set within 68 years of the server before the protocol is
started, correct values are obtained even if the client and server
are in adjacent eras.
谢谢！
我想检查 NTP 的“ntpdate”实用程序是否处理 2036 翻转问题。为此，我想实现一个 NTP 服务器，它在翻转时间后生成一个静态时间戳：2036-02-07/06:28:15.
我目前还停留在理解 NTP 如何解决这个问题上。我看到 NTPv3 protocol does use 64-bit timestamps (32-bit seconds, 32-bit usec(fraction)) and I also see that new NTPv4 standard defined in rfc5905 page12 通过定义三种不同的数据类型解决了这个问题。
There are three NTP time formats, a 128-bit date format, a 64-bit timestamp format, and a 32-bit short format
但是在page 18中定义的“包头格式”中，使用的时间戳只包含64位时间戳格式。文档中没有其他地方提到我们如何合并“128 位日期格式”，其中包括为解决翻转问题而定义的“纪元”和“纪元偏移”数据。
“ntpdate”实用程序声称它支持 NTPv4 标准，所以我猜它也应该支持 128 位时间戳。我还查看了 ntpdate 的源代码，看看是否支持“时代”或“128 位时间戳”格式，但我找不到任何指示 'ntpdate' 可以处理的指针128 位时间戳。
据我了解，NTP在NTPv4协议中引入了一种128位的日期格式，应该用来解决翻转问题。我的理解正确吗？是否有任何其他在线开源服务器可用于调查 'ntpdate' 或 'ntpd' 实用程序针对 2036 年翻转问题的行为？
提前致谢！
经过大量研究，我想出了这个 link，问题解释得很清楚。
事实证明，我们总是可以只发送定义的 64 位格式的时间戳，而不用担心时代的问题。 Charpter 6 of rfc5905中解释了如何从Prime-epoch时间确定时间戳。
To convert system time in any format to NTP date and timestamp formats requires that the number of seconds s from the prime epoch to the system time be determined. To determine the integer era and timestamp given s,
era = s / 2^(32) and timestamp = s - era * 2^(32)
同上link中的例子进行了说明。我仍然想知道为什么 NTPv4 费心去定义“128 位日期格式”以及它究竟用在哪里，但这不是这个问题的范围。
这里可能要添加的限制是：这些计算只适用于相邻的时代，并且只有当客户端设置在服务器的 68 年内，因为签名的艺术。引用自 Section 6, Page 5
In point of fact, if the client is set within 68 years of the server before the protocol is started, correct values are obtained even if the client and server are in adjacent eras.
谢谢！