The most important thing to observe about the NTP timescale is that it is reckoned from 0 January 1900 (sic) and counts the seconds since then. It knows nothing about days, years or centuries, only the seconds. On 1 january 1970 when Unix life began, the NTP clock read 2,208,988,800, and when the Coordinated Universal Time (UTC) era began on 1 january 1972, it read 2,272,060,800. On the last second of this millennium, the NTP clock will show 3,155,672,599 and one second later on the first second of the next will show 3,155,673,600. Other than this observation, the NTP timescale has no knowledge of or provision for either of these eclectic seconds.
The NTP timestamp format is a 64-bit quantity, 32 bits of which number the seconds. Thus, the NTP timescale wraps around in 136-year cycles, the next of which will begin in 2036. Assuming this format is still in use at that time, provisions must be made to qualify time values for the next cycle. There are many ways this could be done, some of which may be suggested by the discussion later in this document. Meanwhile, this is an issue that can be deferred until well after the millennium epoch.
The NTP timescale is almost never used by system or application programs. The generic Unix kernel keeps time in seconds and microseconds (or nanoseconds) to provide both time of day and interval timer functions. In order to synchronize to the NTP clock, the kernel must convert to and from NTP representation and Unix representation. Like the NTP timescale, the Unix timescale will wrap around in 136-year cycles, the next of which will begin in 2106. By then, the lessons learned with the NTP cycle should provide adequate precedent.
While incorrect time values due to the NTP timescale, protocol design or reference implementation upon the millennium are highly unlikely, hazards remain due to incorrect software external to the NTP software. One of these hazards is the kernel and library routines which convert kernel time to and from conventional civil time in seconds, minutes, hours, days and years. Although NTP uses these routines to format monitoring data displays, they are not used to read or set the NTP clock. They may in fact cause problems with certain application programs, but this is not an issue which concerns NTP correctness.
While it is extremely unlikely that the NTP will produce a discontinuity upon the millennium epoch, it is possible that some external source to which NTP synchronizes may produce one. The NTP primary (stratum 1) time servers, which are the ultimate time references for the entire NTP population, obtain time from various sources, including radio and satellite receivers and telephone modems. Not all sources provide year information and not all of these provide time in four-digit form. In point of fact, the NTP reference implementation does not use the year information, even if available. Instead, the year information is provided from the file system, which itself depends on the system clock.
Left to itself, the kernel system clock will tick past the millennium
epoch in the same way that the NTP timescale does. Whether NTP or kernel
time values produced after the epoch are converted to the correct time
is an issue, but not of concern to NTP. In any case, the time-of-year timecode
produced by most national time dissemination services is compared with
the file system time. If the discrepancy if over 1000 seconds, an error
alarm is raised requiring manual intervention. This makes it very unlikely
that even a corrupted file system will cause a primary server to deliver
incorrect time values.
It is essential that any clock synchronization protocol, including
NTP, include provisions for multiple-server redundancy and multiple-route
diversity. Past experience has demonstrated the wisdom of this requirement,
which protects clients against hardware and software faults, as well as
incorrectly operating reference sources. For the most reliable service,
we recommend multiple reference sources for primary servers, such as a
radio or satellite receiver and telephone modem. We also recommend that
primary servers run NTP between themselves to provide additional redundancy
and mutual backup.