The NTP Era and Era Numbering

Introduction

As of earky 2009 the Network Time Protocol (NTP) has been ticking over 27 years and remains the longest running, continuously operating application protocol in the Internet. There was some fear, especially in government and financial institutions, that NTP might cause an Internet meltdown upon the Millennium epoch, but those fears turned out to be groundless. However, the concern now is a possible meltdown when the unsigned 64-bit NTP timestamp rolls over in 2036. This section demonstrates that, like the Millenium epoch, the rollover fear also is groundless

It is important to make a careful distinction between the terms timescale, date, epoch, era and timestamp. A timescale is a continuum of values used to denote time in some frame of reference. While those useful for computers and networks are continuous, civil timescales may not be. For instance, in order to align the civil year with the solar year, Pope Gregory punched a 10-day hole in the Common Era (CE) in 1582. In modern times we occasionally insert a leap second to align the civil time to the solar time.

Generally, timescales are cyclic and span an era with designated beginning and span. The timescale corresponding to the Julian Era began in 4713 BCE and spans 7980 years. A date is a unique value captured as the timescale progresses and an epoch is a static date of some interest, such as the origin of the CE. In general, both dates and epoches are internal system variables with generous proportions, like 128 bits. On the other hand, timestamps are derived from dates but packed in more compact format, like 64 bits, for efficiency in transport. NTP timestamps are associated with era numbers that provide an unambiguous mapping to dates.

The UTC Timescale

It will be helpful in understanding the issues raised here to consider the concept of a universal timescale. The conventional civil timescale used in most parts of the world is based on Coordinated Universal Time (UTC), which replaced Greenwich Mean Time (GMT) many years ago. UTC is based on International Atomic Time (TAI), which is derived from hundreds of cesium oscillators in the national standards laboratories of many countries. Deviations of UTC from TAI are implemented in the form of leap seconds, which occur at intervals from a few months to serveral years.

For almost every computer application today, UTC represents the universal timescale extending into the indefinite past and indefinite future. We know of course that the UTC timescale did not exist prior to 1972 CE, nor the Gregorian calendar prior to 1582 CE, nor the Roman calendar prior to 54 BCE, nor the Julian Era prior to 4713 BCE, and we cannot predict exactly when the next leap second will occur. Nevertheless, most folks would prefer that, even if we can't get future seconds numbering right beyond the next leap second, at least we can get the days numbering right until the end of reason.

The NTP Timescale

The UTC timescale can be implemented using a binary counter of indefinite width and with the unit seconds bit placed somewhere in the middle. The counter is synchronized to UTC such that it runs at the same rate and the units increment coincides with the UTC seconds tick. The NTP timescale is defined by 128 bits of this counter, of which the first 64 bits count the seconds and the last 64 bits represent the fraction within the second. The timescale covers well beyond the age of the universe with a precision well below the smallest times that can be directly measured. An implementation may choose to limit the size of the fraction field, but not less than 32 bits.

An NTP date is a twos-complement integer where the prime epoch (epoch 0) corresponds to 0h 1 January 1900. Positive values represent times after then; negative values represent times before then. Conversion between any date format and NTP format is done by computing the seconds and fraction difference between the given date and the NTP prime epoch; the 128-bit signed value is the NTP date.

An NTP timestamp is a truncated NTP date expressed as an unsigned 64-bit integer including the low order 32 bits of the seconds field concatenated with the high-order 32 bits of the fraction field. This format can represent the 136 years from 1900 to 2036 with a precision of 232 picoseconds. As will be shown later, ranges beyond these years require an era number which is the high order 32 bits of the seconds field of the associated date.

The most important thing to observe about the NTP timescale is that it knows nothing about days, years or centuries, only the seconds and fraction relative the prime epoch. The following table illustrates the correspondence between calendar date, Julian day number (JDN), NTP date, NTP era and NTP timestamp. Prior to 15 October 1582 CE, JDN years are reckoned in 365.25 days; after that, JDN years are reckoned in the Gregorian calendar. Most historians and Julian calculators do this to avoid Pope Gregory's ten-day hole.

Calendar Date	JDN	NTP Date	NTP Era	NTP Timestamp
1 Jan 4713 BC	0	-208,657,814,400	-49	1,795,583,104
1 Jan 1 CE	1,721,426	-59,926,608,000	-14	202,934,144
15 Oct 1582	2,299,161	-10,010,304,000	-3	2,874,597,888
1 Jan 1900	2,415,021	0	0	0
1 Jan 1970	2,440,588	2,208,988,800	0	2,208,988,800
1 Jan 1972	2,441,318	2,272,060,800	0	2,272,060,800
7 Feb 2036	2,464,731	4,294,944,000	0	4,294,944,000
8 Feb 2036	2,464,732	4,295,030,400	1	63,104
1 Jan 3000	2,816,788	34,712,668,800	8	352,930,432

Note the correspondence between the NTP date on one hand and the NTP era and timestamp on the other. The signed era number provides the base epoch in multiples of 2³² and the unsigned timestamp the offset in that era. Conversion between date and era-timestamp formats can be done by simple cut and paste requiring no arithmetic operations.

The NTP timescale is almost never used directly 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 the Unix clock, NTP software must convert to and from NTP representation and Unix representation. Most Unix kernels implement the time of day function using two signed 32-bit counters, one representing the seconds since Unix life began at 0h 1 January 1970 and the other the microseconds or nanoseconds of the second. In principle, the seconds counter will change sign in 68-year epochs, the next of which will happen in 2038. How the particular Unix system copes with this epoch is of concern, but is beyond the scope of discussion here.

The most probable solution when 2038 comes near is to replace the 32-bit seconds counter with a 64-bit counter, and some kernels have already done that. Certainly a 64-bit counter can be used in the NTP software, but this can't be done in messages exchanged over the network, as the seconds values are contained in 32-bit fields in the TIME and NTP protocols and can't be changed without causing awkward compatibility issues, especially as some provision would have to be made to operate with both 32-bit and 64-bit fields.

The NTP Era

The correctness principles on which NTP is based require all clock adjustments to be additive; that is, the only operations permitted are to advance or retard the clock, but never set it directly. NTP timestamp operations conform to this requirement and continue to work even when the era rolls. However, the precise epoch of a roll might not be available when the offset and delay values are determined, as these computations are done in real time and involve 32-bit NTP timestamps. However, careful analysis shows that the NTP calculations remain valid even when the server and client are in different eras, as long as the client is set within 68 years of the server.

Current implementations of the Unix system clock and NTP daemon operate with four 64-bit raw timestamps. The only arithmetic operation permitted on raw timestamps is subtraction, which produces signed 63-bit timestamp differences from 68 years in the past to 68 years in the future. The offset and delay calculations involve addition and subtraction of these differences to produce signed 62-bit values. To avoid overflow in these calculations, timestamp differences must not exceed from 34 years in the past to 34 years in the future. This is a fundamental limit in 64-bit integer calculations. However, the NTP reference implementation converts the timestamp differences to floating doubles, so the offset and delay are valid from 68 years in the past to 68 years in the future.

When computing timestamp differences and the timestamps are in the same era, the differences can be calculated directly. If not, in all credible cases the two eras will be adjacent to each other; that is, if one timestamp is in era n, the other will be either in era n - 1 or n + 1. Consider the case in the following figure, where timestamps are represented as years mod 136. Server clock S is set to 2056 (timestamp 20 in era 1), while the client clock C is set to 2006 (timestamp 106 in era 0).

If C is set within 68 years of S, S can be anywhere between 1938 (timestamp 38 in era 0) and 2074 (timestamp 38 in era 1). If S is between 38 and 136, S and C are in the same era and the difference is S - C. If S is between 0 and 38, S is in the next higher era and the difference is S - (136 - C), in this case 50. Similarly for S, if C is between 0 and 88, the timestamps are in the same era and the difference is C - S. Finally, if C is between 88 and 136, the difference is -(136 - C) - S, in this case -50.

In general, if m is the modulus of the seconds counter, in NTP 2³², then m - x = -x mod m. In the case above, C is a negative number in twos-complement arithmetic, so the server offset from the client is S - C and the client offset from the server is C - S, no matter if S and C are in the same or adjacent eras.

As mentioned before, to convert system time in any format to NTP format requires only that the number of seconds s from the prime epoch to the system time be determined. The era number is the integer quotient 2³² / s and the timstamp is the integer s mod 2³². To convert from NTP era number and format to system time requires only the calculation s = 2³² * era + timestamp to determine the number of seconds since the prime epoch. Converting the corespondence between s and system time is a little messy. Note that the number of days in era 0 is one more than the number of days in most other eras and this won't happen again until the year 2400 in era 3.