NTP era 0 — 7 February 2036, 06:28:16 UTC

NTP versions 3 and 4 put the time in an unsigned 32-bit seconds field counted from 1 January 1900. That field wraps at 06:28:16 UTC on 7 February 2036, about 23 months before the Unix overflow.

Wrap	`2036-02-07 06:28:16 UTC`
Field	32-bit unsigned seconds in the NTP timestamp
Epoch	1900-01-01 00:00:00
Era length	2³² seconds, about 136 years
Era on the wire	Not transmitted in NTPv3/v4. The client infers it.

Why a 64-bit server still cares

The operating system can have a 64-bit time_t and still speak 32-bit NTP on the network. ntpd, chrony and appliance firmware reconstruct the full date by assuming the local clock is already within half an era of the truth. That works if the clock is roughly right. It fails if the clock is decades off.

The ugly pairing is with Unix Y2038. A 32-bit host that wraps to December 1901 is more than 68 years wrong. An NTP client that then guesses the era from that clock can lock to the wrong century and stay there.

What to check

ntpq -c rv | head
chronyc tracking
# note the reference time and the leap status, not just "synchronised"

On an appliance, the question is whether the NTP stack was built with a 64-bit era or still pivots on a 32-bit system clock. Vendor notes from Mills (“Year 2036”) and from Meinberg’s rollover pages are the usual primary write-ups. A datasheet that says “NTP client” is not.

What this is not

It is not the leap-second problem, and it is not the GPS week roll on 20 November 2038. Those are separate counters. A site that only tests date -s on the Unix clock has not tested NTP.