NTP Era 2036
In brief: The Network Time Protocol keeps the world's computer clocks in sync. Its packets carry time as a 32-bit count of seconds since 1 January 1900. That counter fills up and wraps to zero at 06:28:16 UTC on 7 February 2036, almost two years before the Unix 2038 overflow. The NTP standard defines numbered "eras" so that well-written software can tell 2036 from 1900. Simple clients, especially embedded devices with no battery-backed clock, may still set themselves to the wrong century.
| Risk level | Medium (High for embedded SNTP clients without an RTC) |
| Status | Era handling is specified in RFC 5905 (2010) and RFC 4330 (2006). The ntp.org reference implementation has been tested by its maintainers. Behaviour of other clients varies |
| Last reviewed | 2026-10-21 |
2038 status at a glance
- At risk ConfirmedSNTP clients without a battery-backed clock (routers, cameras, PLCs, IoT)NTP's 32-bit seconds field wraps on 2036-02-07, two years before 2038. Devices that boot without a real-time clock can't tell which era they are in, and may jump to 1900 or the wrong era.Do: Use era-aware NTP software, add an RTC or a firmware time floor, and test boot behaviour after 2036.
- DependsPTP (IEEE 1588)The protocol uses 48-bit TAI seconds, but 32-bit implementations must handle all 48 bits.Do: Check embedded PTP stacks.
Not affected or different deadline (1), and why
- Not affectedFull NTP daemons (ntpd, NTPsec, chrony) with a working clockThey resolve the era from the system clock or build date, and ntp.org has tested the 2036 transition.Do: On 32-bit systems they still depend on a 64-bit time_t for 2038.
Overview
NTP timestamps are 64 bits: a 32-bit unsigned seconds field and a 32-bit fraction. The seconds count starts at the prime epoch, 0h 1 January 1900 UTC [1]. An unsigned 32-bit value holds 2³² = 4,294,967,296 seconds, about 136 years, so the field wraps in 2036:
1900-01-01 00:00:00 UTC + 2^32 s = 2036-02-07 06:28:16 UTC (first instant of NTP era 1)
(Arithmetic from the RFC 5905 epoch. RFC 4330 gives the same instant, "6h 28m 16s UTC on 7 February 2036" [2].)
RFC 5905 states: "Era 0 includes dates from the prime epoch to some time in 2036, when the timestamp field wraps around and the base date for era 1 is established" [1]. Its table of historic NTP dates lists 8 Feb 2036 as the "First day NTP Era 1" (the first full day) [1].
Because NTP was built on unsigned arithmetic from 1900, its limit (2036) comes before the signed-1970 Unix limit (2038). The two are separate problems. A device can handle the NTP era correctly and still fail in 2038 if its operating system uses a 32-bit time_t [3]. See Year-2038-Problem.
The rollover has been known since at least 1989. RFC 1119 (NTP version 2, September 1989) noted that "since some time in 1968 the most significant bit (bit 0 of the integer part) has been set and that the 64-bit field will overflow some time in 2036". It added that "some external means will be necessary to qualify time relative to 1900 and time relative to 2036 (and other multiples of 136 years)" [5]. The ntp.org reference library describes the later design in the same terms. A signed era number gives the base epoch in multiples of 2³² seconds, and the unsigned timestamp gives the offset within that era [6].
Technical details
Formats in RFC 5905
| Format | Size | Seconds field | Range | Used in |
|---|---|---|---|---|
| Short | 32-bit | 16-bit unsigned + 16-bit fraction | ~18 h | Delay and dispersion fields |
| Timestamp | 64-bit | 32-bit unsigned seconds + 32-bit fraction (232 ps) | 136 years | Packet headers |
| Date | 128-bit | 64-bit signed (32-bit Era Number + 32-bit Era Offset) + 64-bit fraction | 584 billion years | Internal use only |
Source: RFC 5905 §6 [1].
The era number is not sent on the wire. RFC 5905 says: "Eras cannot be produced by NTP directly, nor is there need to do so. When necessary, they can be derived from external means, such as the filesystem or dedicated hardware" [1]. Meinberg's knowledge base makes the same point: up to NTPv4, "the era number is not transmitted in the NTP network packets" [3].
Conversion between seconds since the prime epoch s and (era, timestamp) is defined as [1]:
era = s / 2^32
timestamp = s - era * 2^32
s = era * 2^32 + timestamp
Why correctly written NTP survives the wrap
NTP's offset and delay calculations use differences of timestamps in two's-complement arithmetic. RFC 5905 §6 says: "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" [1]. RFC 5905 §8 adds a tighter limit for pure 64-bit integer arithmetic. The offset and delay calculations combine sums and differences, so "the time of the client must be set within 34 years of the server before the service is started". Using floating-point for the second-order terms restores the 68-year range [1].
In practice, a client that already roughly knows the date stays correct across the wrap. A client that boots with a clock of 1970 or 1900 and trusts the first raw timestamp may not.
The SNTP convention (RFC 4330)
The older SNTPv4 specification (RFC 4330, January 2006, now obsoleted by RFC 5905) gave simple clients a fixed rule based on the top bit [2]:
If bit 0 is set, the UTC time is in the range 1968-2036, and UTC time is reckoned from 0h 0m 0s UTC on 1 January 1900. If bit 0 is not set, the time is in the range 2036-2104 and UTC time is reckoned from 6h 28m 16s UTC on 7 February 2036.
This is a windowing fix very similar to Y2K windowing (see Y2K-Remediation-and-Cost). It moves the problem to 2104. RFC 4330 also warns that clients must be "within 34 years of the server time before the client is launched" and that, since the Unix epoch of 1970 is now more than 34 years ago, devices need a time-of-year chip or firmware to start the clock closer to the present [2].
How implementations pick the era
| Implementation | Approach | Ref |
|---|---|---|
ntp.org reference ntpd |
Rollover "successfully tested quite some time ago by one of the maintainers" | [3] |
| NTPsec | Uses a pivot date equal to the build date and chooses the era closest to it. Correct while communicating instances' pivots are within half a cycle (~68 years) of each other. Near a boundary, the result may fall in the previous or next era | [4] |
| SNTP clients following RFC 4330 | Top-bit window 1968–2104 | [2] |
| Ad-hoc embedded SNTP code | Often unix = ntp_seconds - 2208988800 in 32-bit arithmetic, with no era handling (general pattern; no specific product verified) |
n/a |
The NTP-to-Unix offset is 2,208,988,800 seconds, the NTP timestamp of 1 January 1970 [1]. After the wrap, an unsigned 32-bit NTP value is smaller than this offset. Code that subtracts without era handling produces either a negative value (read as before 1970) or, in unsigned arithmetic, a value near 2106.
Note on NTPsec's "half-cycle" figure: NTPsec's documentation describes the half-cycle as "88 years" [4]. Half of the 136-year NTP cycle is 68 years, so "88" appears to be a typo in that document.
Affected versions / products
| Component | Exposure |
|---|---|
| Full NTP daemons (ntpd, NTPsec, chrony) on systems with a working RTC | Low. Era resolved from the system clock or build date [3][4] |
| SNTP clients in routers, cameras, PLCs and IoT devices without a battery-backed RTC | High. Hard to determine the era at boot [3] |
Devices that also use 32-bit time_t |
Fail again in 2038 even if NTP is fixed [3] |
| GPS-disciplined NTP servers | Also exposed to the GPS-Week-Rollover (2038-11-20/21) |
| PTP (IEEE 1588) | Uses 48-bit TAI seconds, which will not roll over soon, but 32-bit implementations must handle the full 48 bits [3] |
Risk & compliance notes
- Timeline: 2036-02-07 is less than ten years after this page's review date. It falls before 2038, so 2038 test plans should include a 2036 NTP scenario.
- Inventory: For each device, record the SNTP client library, whether there is an RTC, the firmware build date, and whether
time_tis 32-bit. - Ownership: Timing problems spread. One bad server can set many clients to the wrong era. Assign ownership of the time-distribution chain, as the Telstra 2026 incident showed for GPS (see GPS-Week-Rollover).
Detection & mitigation
- Test with a fake server. Run an NTP server with its clock set past 2036-02-07 in an isolated lab and observe how clients behave from both a cold boot and a warm (already-synced) state.
- Give clients a starting point. Meinberg's suggested workaround for devices without an RTC is to set the initial system date to the firmware release date [3].
- Prefer era-aware software. Use maintained NTP implementations, and avoid hand-written SNTP parsing.
- Check the whole chain. Meinberg recommends verifying reference sources (GNSS, DCF77, IRIG), the OS and the NTP/PTP services on servers, and era-aware software and a Y2038-safe OS on clients [3].
See Testing-and-Detection and Remediation-Guide.
See also
- Related-Date-Bugs
- GPS-Week-Rollover
- Year-2038-Problem
- Year-2106-and-Beyond
- File-Formats-and-Protocols
- Devices-Networking-and-IoT
References
- RFC 5905: Network Time Protocol Version 4: Protocol and Algorithms Specification — Mills, Martin, Burbank, Kasch, IETF, June 2010. §6 data types, prime epoch, eras, Figure 4, and the 68-year rule; §8 the 34-year limit.
- RFC 4330: Simple Network Time Protocol (SNTP) Version 4 — D. Mills, IETF, January 2006. The bit-0 convention for 1968–2036 / 2036–2104 and the 34-year start-up requirement.
- Time synchronization and rollovers — Martin Burnicki, Meinberg Knowledge Base (updated 2025-03-20). Era not on the wire, ntp.org testing, embedded risks, PTP and recommendations.
- Rollover issues — NTPsec documentation. Era 1 on 2036-02-07 and the build-date pivot.
- RFC 1119: Network Time Protocol (Version 2) Specification and Implementation — D. Mills, September 1989 (ntp.org archive PDF). §3.1 timestamp format: bit 0 set since 1968, overflow in 2036, external means needed to tell 1900 from 2036.
- The NTP Era and Era Numbering — NTP reference library, ntp.org (last updated 2022-06-24). Signed era number plus unsigned timestamp; 2036 rollover concern.