Introduction
The conventional civil timescale used in most parts of the world is based on Coordinated Universal Time (UTC sic). UTC is based on International Atomic Time (TAI sic), which is derived from hundreds of cesium clocks 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 several months to several years. This page considers what happens in the NTP timescale upon the epoch of a leap second.
While TAI is useful in the scientific community, most of us reckon time according to the Sun and season. Starting from TAI, the UT0 timescale is determined using corrections for Earth orbit and inclination (the Equation of Time as used by sundials). The International Earth Rotation Service (IERS) at the Paris Observatory uses astronomical observations provided by USNO and other observatories to determine the UT1 (navigator's) timescale corrected for irregular variations in Earth rotation.
How UTC Reckons with Leap Seconds
While UT1 defines the solar day, adopting it would require resetting our clocks some fraction of a second every month or two. On the epoch 0h 1 January 1972 ET, UTC was defined TAI - 10 s, within 0.5 s of UT1, but the offset TAI - UT1 has been slowly increasing since then; in mid 2007 it is 33 s. When the offset UT1 - UTC becomes greater than about 0.5 s, a leap second is inserted in the UTC timescale. The residual difference is called the DUT1 correction in broadcast timecode formats and is represented in deciseconds (0.1 s).
For the most precise coordination and timestamping of events since 1972, it is necessary to know when leap seconds were implemented in UTC and how the seconds are numbered. This is currently the responsibility of the IERS, which publishes periodic bulletins available on the Internet. As specified in CCIR Report 517 and later revised, a leap second is inserted following second 23:59:59 on the last day of any designated month and becomes second 23:59:60 of that day. A leap second would be deleted by omitting second 23:59:59 on one of these days, although this has never happened.
Leap seconds were inserted prior to 1 January 2006 on the occasions listed in the leapseconds file, a current copy of which can be obtained from NIST or via the NTP Autokey security protocol. The intervals between leap insertions has been increasing; the interval since the next scheduled leap second at the end of 2005 and the last one at the end of 1998 was seven years.
The UTC timescale thus ticks in standard TAI seconds and was set TAI - 10 s at 0h MJD 41,317.0 according to the Julian-day calendar or 0h 1 January 1972 according to the Gregorian calendar. This established the first tick of the UTC era and its reckoning with these calendars. Subsequently, the UTC timescale has marched backward relative to the TAI timescale exactly one second on scheduled occasions recorded in the institutional memory of our civilization. Note in passing that leap second adjustments affect the number of seconds per day and thus the number of seconds per year. Apparently, should we choose to worry about it, the UTC clock, Gregorian calendar and various cosmic oscillators will inexorably drift apart with time until rationalized by a future papal bull.
While of less use to the computer timekeeper, the Global Positioning System (GPS), which is widely used to disseminate standard time, has its own timescale. The GPS timescale is syntonic with TAI, but at a fixed time offset of -19 s from that timescale, apparently because the final system design review was in 1980. GPS clocks typically convert from GPS to UTC for external readings.
How NTP Reckons with Leap Seconds
The NTP timescale is based on the UTC timescale, but not necessarily always coincident with it. Upon the first tick of UTC at 0h 1 January 1972 the NTP clock read 2,272,060,800, representing the number of standard seconds since the latest NTP era began at 0h 1 January 1900. The insertion of leap seconds in UTC and subsequently into NTP does not affect the UTC or NTP oscillator, only the conversion between NTP network time and UTC civil time. However, since the only institutional memory available to NTP are the UTC broadcast services, the NTP timescale is in effect reset to UTC as each broadcast timecode is received. Thus, when a leap second is inserted in UTC and subsequently in NTP, knowledge of all previous leap seconds is lost.
Another way to describe this is to say there are as many NTP timescales as historic leap seconds. In effect, a new timescale is established after each new leap second. Thus, all previous leap seconds, not to mention the apparent origin of the timescale itself, lurch backward one second as each new timescale is established. If a clock synchronized to NTP in 2005 was used to establish the UTC epoch of an event that occurred in early 1972 without correction, the event would appear 22 seconds late. However, NTP primary time servers resolve the epoch using the broadcast timecode, so that the NTP clock is set to the broadcast value on the current timescale. As a result, for the most precise determination of epoch relative to the historic Gregorian calendar and UTC timescale, the user must subtract from the apparent NTP epoch the relevant offset provided by the IERS. This is a feature of almost all present day time distribution mechanisms.
The detailed chronometry involved can be illustrated with the help of the table below, which shows the details of seconds numbering just before, during and after a leap insertion after 23:59:59 UTC 31 December 1998. The NTP leap bits are set by the protocol on the day of insertion, either directly by a reference clock driver or indirectly by the protocol. The NTP compliant kernel inserts the leap second following a normal day of 86,400 seconds, then resets the leap bits.
|
Date
|
Time
|
TAI Offset
|
NTP Leap
|
NTP Seconds
|
|
31 Dec 98
|
23:59:59
|
31
|
01
|
3,124,137,599
|
|
23:59:60
|
31
|
01
|
3,124,137,600
|
|
|
1 Jan 99
|
00:00:00
|
32
|
00
|
3,124,137,600
|
|
00:00:01
|
32
|
00
|
3,124,137,601
|
While the last second of a normal day is 23:59:59, the last second of a leap day is 23:59:60. Since this makes the day one second longer than usual, the day rollover will not occur until the end of the first occurrence of second 3,124,137,600. The kernel time conversion routines can recognize this condition and show the leap second as number 60.
Immediately after the leap second insertion, both timescales resume ticking the seconds as if the leap had never happened. The chronometric correspondence between the UTC and NTP timescales continues, but NTP has forgotten about all past leap insertions. Thus, determination of UTC time intervals spanning leap seconds will be in error, unless the exact times of insertion are known from the NIST table and its successors.
Note that the NTP Seconds column in the table above actually shows the epoch of the leap second itself, which is the precise epoch of insertion. The TAI Offset column shows the cumulative seconds offset of UTC relative to TAI; that is, the number of seconds to add to UTC in order to maintain nominal agreement with TAI. Finally, note that the epoch of insertion is relative to the timescale immediately prior to that epoch; e.g., the epoch of the 31 December 1998 insertion is determined on the timescale in effect just prior to this insertion, which means the actual insertion relative to TAI is 21 seconds earlier than the apparent time on the UTC timescale.
The obvious question raised by this scenario is what happens during the leap second itself when NTP time stops and the clock remains unchanged. If the precision time kernel modifications have been implemented, the kernel includes a state machine that implements the actions required by the scenario. At the first occurrence of second 3,124,137,600, the system clock is stepped backward one second. However, the routine that actually reads the clock is constrained never to step backwards, unless the step is significantly larger than one second, which might occur due to explicit operator direction. In this design time stands still during the leap second, but is correct commencing with the next second.
The figure above shows the behavior with the modified design used in most kernels. The clock reading is constrained to always increase, so every reading during the leap second increases the software clock by one increment, usually one nanosecond (one microsecond in older kernels). In case A the clock was not read during the leap second, so apears to stand still. In case B the clock was read one or more times during the leap second, so the value increments beyond the last reading. This will persist until after the leap second the stepped-back clock catches up to this value. Means should be provided to protect against runaway if it is possible to read the clock more than once during one increment.
