NTPv5 Is an Active IETF Draft
The IETF Network Time Protocol working group has an active March 2026 Internet-Draft for Network Time Protocol Version 5. The draft is not a finished RFC and explicitly remains work in progress, but it is a useful signal for timestamp and clock-synchronization software because it sketches the next protocol shape for distributing time over UDP. Its abstract says NTPv5 keeps only a client-server model and removes legacy operational modes to improve robustness and clarity.
The Protocol Names the Timescale
NTPv5 adds an explicit Timescale field. Requests can ask for a timescale, and responses identify the timescale used by their receive and transmit timestamps. The defined values are UTC, TAI, UT1, and leap-smeared UTC. That is a practical improvement for systems that otherwise treat "network time" as one undifferentiated value even though UTC leap seconds, continuous atomic time, Earth-rotation time, and smeared time have different behavior at boundaries.
Leap Smearing Becomes Visible to Clients
The draft also makes leap-second handling more explicit. It says the Leap Indicator signals a scheduled leap second for UTC responses, but a leap-smeared response uses the normal value because the client is not expected to apply a leap second itself. A client synchronized to a leap-smeared timescale must not apply leap seconds, and if it also serves time to downstream clients it should preserve that smeared timescale. That reduces one common failure mode: combining a smeared source with a second leap-second correction.
NTP Era Handling Matters Before 2038
NTP timestamps do not use the Unix epoch. RFC 5905 defines NTP time from an assumed 1900 epoch and shows the protocol's era transition arriving in February 2036, before the 2038 signed 32-bit Unix time_t boundary. The NTPv5 draft keeps a 64-bit timestamp format with 32 integer bits and 32 fractional bits, but it also carries an 8-bit era field. For clients that count seconds internally with a type wider than 32 bits, the draft says they should expand received timestamps with the provided NTP era.
What Timestamp Systems Should Check
Most web applications still store event instants as Unix epoch seconds or milliseconds, not NTP timestamps. The impact is at the synchronization and conversion boundary: monitoring agents, embedded devices, databases, and logs may depend on NTP to discipline system clocks before those clocks produce Unix timestamps. RFC 8877 treats epoch, wraparound, and leap-second behavior as attributes that packet timestamp formats should spell out. Code that parses NTP packets, bridges UTC and TAI, handles leap smearing, or assumes every network-time value is UTC should track the NTPv5 draft and keep tests that cover leap-second flags, smeared sources, and the 2036 NTP era boundary separately from the 2038 Unix overflow problem.