Nº 7 2013 > The future of time –
To abolish or not to abolish the leap second?

Impact of leap seconds on digital time services
Internet time servers

Judah Levine, Time and Frequency Division, United States National Institute of Standards and Technology

Working in an Internet server roomJudah LevineUltra-stable ytterbium lattice atomic clock at the National Institute of Standards and Technology (NIST), United States. Ytterbium atoms are generatedImpact of leap seconds on digital time services Internet time servers
Working in an Internet server room
Judah Levine
Ultra-stable ytterbium lattice atomic clock at the National Institute of Standards and Technology (NIST), United States. Ytterbium atoms are generated in an oven (large metal cylinder on the left) and sent to a vacuum chamber (centre of the photo) to be manipulated and probed by lasers. The tick of the ytterbium clock is said to be more stable than that of any other atomic clock

The National Institute of Standards and Technology (NIST) operates 45 Internet time servers that are located at sites in the United States. These servers include the computing facilities used by the major stock and commodity exchanges in New York and Chicago. The servers are synchronized to Coordinated Universal Time (UTC), as realized at NIST.

Time formats

The NIST servers respond to requests for time in three different formats: the network time protocol (NTP), the DAYTIME format, and the TIME format.

NIST also operates two servers that provide only authenticated NTP-format time messages to users who have registered with NIST. The authentication is realized by adding a hash value to the response. The hash value is computed on the ordinary message combined with a secret key, which is different for each user. The algorithm guarantees that the message originated from an NIST time server and was not modified in transit. This service is used by foreign and domestic commercial and financial institutions.

The time of an NIST server is represented internally as the number of UTC seconds and fractions of a second since the reference epoch, which is 1970.0.

The NTP and TIME format messages represent the time as the number of UTC seconds (and fractions of a second for NTP) since the corresponding reference epoch, which is 1900.0. The DAYTIME format represents the time as a text string in the form hh:mm:ss, with the seconds fraction as a separate parameter.

Consumer choice

The ensemble of time servers receives approximately 75 000 requests per second (some 6.5 thousand million per day). About 85 per cent of these requests are for time in the NTP format, and the remaining 15 per cent are approximately equally divided between the DAYTIME and TIME formats.

The NTP message exchange includes a measurement of the network delay and is potentially more accurate than either the DAYTIME or TIME formats, but all three formats are still widely used.

Our efforts to encourage users of the TIME format to switch to the more accurate NTP format have met with only limited success.

Leap second glitch

The binary format used for the internal system time, and for the NTP and TIME messages, cannot represent the correct time during a positive leap second. Therefore, a positive leap second is represented by repeating the binary value corresponding to 23:59:59 a second time.

The sequence of binary time values during a leap second is equivalent to the UTC time values of 23:59:58, 23:59:59 (first time), 23:59:59 (second time), followed by 00:00:00 of the next day. The internal system software can distinguish between the two identical time values of 23:59:59, but there is no provision in either the NTP or TIME message formats for transmitting this information to a user. The NIST time servers will receive approximately 150 000 requests during the 2-second interval where the integer second corresponds to a UTC time of 23:59:59, so that this is not a negligible problem.

The ambiguity of a time response with an integer second corresponding to 23:59:59 has several important consequences. The first is that the time ordering of events is ambiguous. For example, a time stamp of 23:59:59.1 can occur both before and after a time stamp of 23:59:59.5. Similar ambiguities occur with time intervals measured across a leap second. These short-time intervals play an important role in high-frequency trading and data acquisition.

Another method of implementing a positive (or negative) leap second is to amortize the extra second over some time interval by applying a negative (or positive) frequency offset to the system clock. This method guarantees that the system time will be monotonic, but the time messages transmitted by this type of system will be incorrect during the amortization interval and will differ from the UTC time received from other sources by a varying amount. Time intervals measured during the amortization period will also be incorrect for the same reason. The amortization interval is not specified in any standard. This will lead to different ways of implementing this method, which will result in time values that do not agree with each other during the different amortization intervals. My view is that this method raises more problems than it fixes; it is not used by the NIST servers and is not part of the standard NTP distribution at www.ntp.org.

These effects are much more significant now than they were in 1972 when the leap-second system was introduced. In the first place, automated computer-based financial transactions are no longer limited to the traditional working day, and a leap second near midnight has about the same impact as one during the middle of the day. In the second place, the leap second event, which is defined with respect to UTC, can occur in the middle of a working day in most of Asia and Australia, and these areas have much greater economic activity than they had in 1972. California and other states in the western part of the United States have the same problem.

The NTP and DAYTIME formats provide advance notice of an upcoming leap second. Unfortunately, many common operating systems do not parse the flag. The TIME format has no ability to provide this advance notice. In all of these cases, the clock in the client system will have a time error of 1 second immediately after the leap second has occurred. This time error will persist until the client system requests the time from the server. This "polling interval" varies from one system to another; it may be as short as 64 seconds or as long as several hours. The polling interval is not linked to any specific UTC time, so that an ensemble of systems may have clocks that disagree with each other following a leap second — even if all of the systems have the same nominal polling interval.

In the best case, when the client system detects the one-second error it simply adjusts its clock by the appropriate positive or negative value in a single time step. However, client systems that implement a digital servo loop to control the system clock typically have a more complex response to a large time step, and the time error may oscillate before reaching the correct time. In some cases, the servo loop may crash because the system is not designed to cope with a time error greater than 128 milliseconds. In other implementations, the system treats a one-second error as a network glitch, and tries to remedy the situation by asking for the time again. This process obviously will not converge. In some implementations, these problems are so serious that the operators simply shut the system down before a leap second and restart the system after the leap second epoch has passed.

Time is money

The problems of time-ordering, causality and the ambiguity of time intervals in the vicinity of a leap second are not easily remedied because they arise in a fundamental way from the interaction of the binary representation used for time stamps and the occurrence of a positive leap second. During a leap-second correction, the time servers operated by NIST will receive approximately 150 000 time requests when the time transmitted by the server is 23:59:59, and the increasing number of financial transactions that depend on millisecond-level timing are sure to be affected.

The problems associated with the advance notice of a future leap second and how users respond are not fundamental in principle. They could be addressed by abandoning the TIME protocol, which has no advance notice of a leap second, and by ensuring that an application that uses the NTP or DAYTIME protocols parses the leap second flags that are already present and acts on them appropriately.

Despite our efforts over many years, however, a significant number of users have not implemented these suggestions. We know this because the NTP leap second flags are also used to indicate that the server is unsynchronized, and we have a large number of users who do not recognize the unsynchronized message, use the time stamps anyway, and then complain that they have received the wrong time. Our repeated efforts to end support for the TIME protocol have met with widespread resistance from the user community.

In summary, it is my opinion that keeping the difference between Universal Time (UT1) — an astronomical time-scale defined by the Earth’s rotation and used in celestial navigation — and UTC smaller than 1 second is not worth the difficulties I have discussed in this article, and I would advocate discontinuing leap seconds in the future.



Celebrating ITU’s 150 Years

In this issue
No.6 November | December 2015

Pathway for smart sustainable cities:

A guide for city leaders

Pathway for smart sustainable cities|1

Meeting with the Secretary-General:

Official Visits

Meeting with the Secretary-General|1
Latest headlines

Boosting “SMEs” for ICT growth

What can governments do better?

A guide for city leaders

By Silvia Guzmán, Chairman, ITU Focus Group for Smart Sustainable Cities