Leap Seconds and how they are handled by Meinberg Devices and NTP


Leap Seconds Overview

The basic time for mostly all of the world's local time zones is called Coordinated Universal Time, UTC, which is derived from a bunch of atomic clocks which are distributed in several countries all over the world.

The rotation of the earth is not very constant and varies a bit over time, while decreasing the mean rotation speed slowly. This is the reason why so called leap seconds are inserted into the UTC time scale, they adjust process of the UTC time to the real earth rotation.

An overview of the devolution of the earth rotation can be found on a page of the Paris Observatory:
Leap second in UTC, http://hpiers.obspm.fr/eop-pc/earthor/utc/leapsecond.html

The International Earth Rotation and reference Service, IERS, is measuring the true earth rotation and determines when a leap second has to be inserted. Insertion of a leap second is always scheduled for UTC midnight at the end of the last day of a month, preferably for the last day of June or December. In the past all leap seconds had been inserted at either one of those times. Announcements whether a leap second is scheduled or not are published by the IERS in their Bulletin C. The current Bulletin C is published about half a year before the next possible date for a leap second.

The IERS Bulletin C #52 from July 2016 announces a leap second to be inserted at the end of December 31, 2016, at UTC midnight.

Since the leap second was inserted at the same moment all over the world, the local (civil) time of the insertion depends on the local time offset from UTC, e.g. if the time zone is UTC+3h then the leap second will be inserted when the wall clocks show 3 hours after midnight. So in Europe the leap second is inserted during night time, but e.g. in the United States or Asia this happes during normal working hours.

The standard way to count UTC time across a leap second is:

2016-12-31 23.59.57
2016-12-31 23.59.58
2016-12-31 23.59.59
2016-12-31 23.59.60 <-- leap second
2017-01-01 00.00.00
2017-01-01 00.00.01
2017-01-01 00.00.02
In local time counting depends on the time zone offset, e.g. for UTC+3h you would observe the following:

2017-01-01 02.59.57
2017-01-01 02.59.58
2017-01-01 02.59.59
2017-01-01 02.59.60 <-- leap second
2017-01-01 03.00.00
2017-01-01 03.00.01
2017-01-01 03.00.02
Leap seconds are a discontinuity of civil time. The time does not continue to increase monotonically but it is stepped by one second. Let's have a look at the time stamps of a leap second which is inserted, and the second after that leap second:

2016-12-31 23.59.60 <-- leap second
2017-01-01 00.00.00
We can normalize the time and date of the leap second:
60 seconds are 1 minute, which lets the minutes increment from 59 to 60
60 minutes are 1 hour, which lets the hours increment from 23 to 24
24 hours are 1 day, which lets the date increment, and so on.
Finally we can say that both lines represent exactly the same time, or 2 consequent seconds have the same time stamp.

Several time dissemination services also propagate the announcement of a leap second after this has been determined by the IERS. This includes for example the German long wave transmitter DCF77 and the satellite based navigation system GPS, so receivers which decode the signals from those systems can also decode the leap second announcement. Applications which read the time from those receivers can also determine the leap second announcement if this information is included in the applied protocol, e.g the time string transmitted by the receiver.

Please note that time code receivers can only pass the announcement of a leap second to the application, and count the time correctly over that period. It's the task of the application and/or operating system to handle that leap second correctly.


NTP and Leap Seconds

NTP is capable of dealing with leap seconds. Leap second announcements can be received from an upstream NTP server, an external radio clock or GPS receiver, or a leap second table file.

If an NTP daemon detects a leap second announcement it passes the announcement on to its clients, and notifies its own operating system clock of the upcoming leap second, if the operating system is aware of leap seconds. For OS support of leap seconds see below.

Please note the time stamps NTP uses internally just counts the UTC seconds after the epoche, i.e. since year 1900. NTP does neither care about time zones, nor does it use human readable date and time as mentioned in the description of the refclock time strings above.

Of course the internal time stamps may be converted back to human readable format in log or debug messages, but since that conversion may be ambiguous (i.e. the inserted leap second and the next second may have the same time stamp) you will rarely observe the second counting from 59 to 60 and then 00.


Radio Clocks and GPS Receivers

A few days after the bulletin C had been published the GPS satellites already started to broadcast information on the upcoming leap second, so GPS receivers know about the upcoming leap second already some months in advance. Even though the leap second information transmitted by the satellites includes the absolute date of the leap second, e.g. December 31, 2016, there are unfortunately some 3rd party GPS receivers out there which already output a leap second warning for a wrong, earlier date. Meinberg devices like the LANTIME time server series may eventually generate a log message when they receive the leap second information from the GPS satellites. However, the leap second is inserted only at the specified date. DCF77 radio clocks and GPS receivers manufactured by Meinberg send by default a time string once per second which contains date and time in a human readable format, including some status characters one of which announces an upcoming leap second.

In the example output below, <STX> and <ETX> refer to the ASCII characters STX (code 0x02) and ETX (code 0x03).

Announcement of the leap second starts 59 minutes before the leap second:

<STX>D:31.12.16;T:6;U:23.00.57;  U <ETX>
<STX>D:31.12.16;T:6;U:23.00.58;  U <ETX>
<STX>D:31.12.16;T:6;U:23.00.59;  U <ETX>
<STX>D:31.12.16;T:6;U:23.01.00;  UA<ETX>
<STX>D:31.12.16;T:6;U:23.01.01;  UA<ETX>
<STX>D:31.12.16;T:6;U:23.01.02;  UA<ETX>
This is to be compatible with DCF77 receivers, where the LF transmitter starts sending the announcement in the first minute, but the clock can decode those bits only at the end of the first minute, so transmission of the announcement in the serial data stream starts at the second minute.

This happens when the leap second is inserted:

<STX>D:31.12.16;T:6;U:23.59.57;  UA<ETX>
<STX>D:31.12.16;T:6;U:23.59.58;  UA<ETX>
<STX>D:31.12.16;T:6;U:23.59.59;  UA<ETX>
<STX>D:31.12.16;T:6;U:23.59.60;  U <ETX> <-- leap second
<STX>D:01.01.17;T:7;U:00.00.00;  U <ETX>
<STX>D:01.01.17;T:7;U:00.00.01;  U <ETX>
<STX>D:01.01.17;T:7;U:00.00.02;  U <ETX>
Please note that the announcement has already disappeared during the leap second. However, the seconds will be transmitted as 59, 60, 00 which matches the standard way of counting during a leap second.

Please note also that the leap second is introduced at UTC midnight. The 'U' status character in the example time strings above indicates that the time in the string is UTC. If the time string contained local time then the hours rolled over depending on the selected local time offset from UTC.

For example if the time string contained CET = UTC+1h, the output across the leap second would look like this:

<STX>D:01.01.17;T:7;U:00.59.59;   A<ETX>
<STX>D:01.01.17;T:7;U:00.59.60;    <ETX> <-- leap second
<STX>D:01.01.17;T:7;U:01.00.00;    <ETX>
Please note that a space is sent here instead of the 'U' status character in order to indicate that the time in the string is local time (daylight saving not active) depending on the configured time zone.

The full specification of the Meinberg Standard Time String format is available under the following link:


IRIG Time Codes

IRIG time codes are often used to synchronize time between computers and other devices via cables or fiber optic connections.

Several IRIG frame types have been specified to transport time information between two IRIG devices. Most of the commonly used IRIG frames carry the day-of-year and the current time, but they do neither contain the year number which would be required to convert the day-of-year to a calendar date unambiguously in leap years and non-leap years, nor the UTC offset of the transported time, or a leap second announcement.

The IRIG-compatible timecode frame types IEEE 1344 and IEEE C37.118 contain all this information. However, by specification the leap second is announced only about 60 seconds before it actually occurs.

If such an IRIG receiver is used as a reference time source for NTP then there's a good chance the NTP daemon misses the leap second announcement at a polling interval of 64 seconds and thus is unable to handle the leap second correctly. Even if the NTP daemon received the leap second announcement, it was too late to pass the announcement on to the clients, so most of the NTP clients would probably miss the leap second.

This is the reason why in general a leap second file should be installed for NTP if an IRIG receiver is used as reference time source. General information on usage of IRIG signals can be found in the whitepaper IRIG Time Code Basics


Meinberg LANTIME NTP Servers

Most Meinberg LANTIME NTP servers have a built-in reference clock, e.g. a radio clock, or a GPS receiver which receive the leap second announcement from their primary time source, e.g. the long wave transmitter DCF77, or the GPS satellites.

The NTP server software (ntpd) reads the time from its reference clock once every 64 seconds. Since the time string formats normally used by Meinberg reference clocks support the leap second announcement, ntpd detects the announcement at least 64 seconds after the refclock has started to announce it.

The NTP server passes the announcement to its NTP clients by setting the leap indicator flag in the NTP network packets accordingly until the leap second has happened.

During the leap second the LANTIME's ntpd responds with the same time stamp to any client request. Since NTP clients usually don't query the time in intervals shorter than 64 seconds, they normally won't even notice this, but they can evaluate the leap second announcement which is passed in to them as part of the network packets.

We have run a test program against a Meinberg LANTIME NTP server which queries the NTP server 4 times per second. The LANTIME is fed by a reference time source which supplies the leap second inclusive of the announcement as described above. The program prints the time stamp received from the NTP server, and the time stamp converted to human readable date and time.

Here is the result:

C76199FE.ED888F86  2005-12-31 23:59:58.927864
C76199FF.2E4723AA  2005-12-31 23:59:59.180772
C76199FF.6F09C7FF  2005-12-31 23:59:59.433742
C76199FF.B0320104  2005-12-31 23:59:59.688262
C76199FF.F1167664  2005-12-31 23:59:59.941748
C76199FF.FD09E12A  2005-12-31 23:59:59.988431 <-- leap second
C76199FF.FD09E12A  2005-12-31 23:59:59.988431 <-- leap second
C76199FF.FD09E12A  2005-12-31 23:59:59.988431 <-- leap second
C76199FF.FD09E12A  2005-12-31 23:59:59.988431 <-- leap second
C7619A00.35E37585  2006-01-01 00:00:00.210501
C7619A00.76A22B38  2006-01-01 00:00:00.463411
C7619A00.B770BD01  2006-01-01 00:00:00.716563
C7619A00.F823FAB1  2006-01-01 00:00:00.969298
C7619A01.38EEF1BA  2006-01-01 00:00:01.222395
C7619A01.79AF6C69  2006-01-01 00:00:01.475332
C7619A01.BA76965F  2006-01-01 00:00:01.728371
Please note the 4 same time stamps which are received during the leap second.


Operating Systems

Leap Second Handling by Operating Systems

Some operating system clocks are aware of leap seconds, others are not. If an operating system is aware of leap seconds then NTP can pass the leap second announcement to the kernel and it's up to the kernel which way to handle it. Basically there are 3 ways, each of them has specific advantages and disadvantages:

  1. The system clock can be stepped back by 1 second at the end of the leap second. Using this method the time is always exact. However, it does not increase monotonically, it introduces a discontinuity (in fact just how a leap second is defined). Stepping back the time may perturb the ordering of events based on time stamps since an event which has happened shortly after another event may receive a time stamp which is before the time stamp of the other event. This may affect data base applications, etc, which strongly rely on the ordering of events.

  2. The system clock can be hold for 1 second during the leap second. This means that the time must not be stepped back but increases monotonically, thus lessening the negative effects on data base applications. The system clock returns always the same time stamp during the leap second, and the time error increases from 0 to 1 second.

  3. The system clock can be slewed to compensate the discontinuity introduced by the leap second. This lets the system time increase strongly monotonically since all time stamps happen in the correct order, and there are no 2 of the same time stamps. On the other hand, the system time is "wrong" until slewing has completed.

So the way a leap second is handled depends on how this has been implemented in the operating system clock, if leap second handling has been implemented at all.

Linux kernels and most other Unix-like systems care about the leap seconds and handle them correctly. Some systems even add a notification to the system log when the leap second is inserted.

Some operating systems or older kernels may not care about the leap second announcement, so the 1 second offset after the leap second has been inserted is compensated by stepping the clock back. This may happen with some delay, depending on the NTP polling interval and implementation of the operating system clock.

The Windows system clock does not know about leap seconds, either. However, there is a precompiled version of ntpd for Windows available which is capable of slewing the Windows system time quickly in order to account for the insertion of a leap second, without affecting the clock synchronization loop provided by ntpd.

Of course this works only successfully if also the upstream servers or reference time sources also behave well and announce and handle the leap second correctly. We have recorded the time synchronization behaviour during the leap second and present the results below.


Synchronization of the Windows system time

Leap Second under Windows disciplined by NTP

The graphs below illustrate synchronization of the Windows system time by ntpd over the leap second at the end of December, 2005.

The test environment includes ntpd (ntp-4.2.0b@1.1436mbg-xmas-o-win32) from our NTP download page https://www.meinbergglobal.com/english/sw/ntp.htm#ntp_nt running on a PC with a Pentium 4 CPU (3.2 GHz), under Windows XP SP2. The NTP service was configured to use a single Meinberg LANTIME/GPS NTP server as upstream server on the local network.

Data has been recorded by computing the difference between the interpolated Windows system time disciplined by ntpd, and the time stamp taken from a Meinberg GPS PCI card which provides an accuracy of better than 1 microsecond.

The first graph below shows the measured time difference in milliseconds, and the Windows tick adjustment values over time. The time scale is in seconds after start of recording. At the time of leap second insertion there's a 1000 millisecond peak, and the tick adjustment is reduced to half the normal value for a short period:

Leap Seconds

In the graphs above, the lines before and after the leap second are quite flat, so the next graph shows the interesting values with higher resolution:

Leap Seconds

As can be seen above, the time synchronization loop has not been affected by the inserted leap second. Taking into account that the Windows time on this system normally ticks in 15 millisecond increments only, and higher resolution is only achieved by interpolation, the results are quite good.