5

Wikipedia claims that NTPv4 supports 128-bit timestamps and indeed RFC5905 defines a 128-bit format called "NTP Date Format" in Sect. 6. The RFC says

The 128-bit date format is used where sufficient storage and word size are available.

However, when I send 128-bit timestamps to public NTP servers, there is no response. Furthermore, Sect. 7.3 defines all four timestamp fields to be 64-bit. To avoid Y2k38 bugs, I want to implement NTP properly using 128-bit timestamps. How can I get a server to respond with full 128-bit timestamps?

2
  • ntpdate seems to do it: reference time: e1d49463.09878698 Thu, Jan 23 2020 22:53:39.037 originate timestamp: e1d49469.1247687f Thu, Jan 23 2020 22:53:45.071 transmit timestamp: e1d49469.0d789064 Thu, Jan 23 2020 22:53:45.052
    – stoney
    Commented Jan 23, 2020 at 21:55
  • No, those are 64-bit timestamps (32 bit integer and 32 bit fractional, both 8 hex digits). The 128-bit format has 64-bit integer and 64-bit fractional. Commented Jan 24, 2020 at 7:03

1 Answer 1

0

Old question but I stumbled here looking for the same thing. Page 13 of RFC5905 details that the expanded v4 format still contains a 32-bit value for seconds, but a signed 32-bit value for the era number. The seconds field in 128-bit date format is the offset within the era, so can handle dates far beyond 136 years. Seconds from prime epoch (1970) = era*(2^32) + era_offset(32bit seconds).

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .