Leap Second Testing - Introduction

The GPS satellites transmit a UTC correction parameter set that can be used by receivers to convert the linear GPS system time to UTC.

The offset to be applied is an integer number of seconds, which in fact represents the total number of leap seconds that have occurred since the GPS system was put into operation in January 1980.

The parameter set sent by the GPS satellites provides both the UTC offset before and after the next leap second event.

As long as the 2 offset values in the UTC parameter set are the same (e.g. 18/18 at the time this article is written), no leap second is scheduled, and the nearest leap second date in the parameter set may be ambiguous.

Leap second announcements are published about 6 months before the leap second date, so if the International Earth Rotation And Reference Systems Service (IERS) has issued a leap second announcement, the satellites broadcast the associated information a couple of months in advance, which lets a receiver know about the upcoming leap second, and the exact point in time when the leap second is to be handled.

Soon after the leap second, the satellites start broadcasting both offsets with the same new value.

For example, the UTC offset values sent by the GPS satellites to announce the leap second for 2016-12-31 were 17/18, and shortly after the leap second, the numbers changed to 18/18.

However, even if GPS receivers are informed internally about an impending leap second months in advance, the time from which the announcement is forwarded to other programs may be much later, e.g. just 24 hours before the leap second event.

GPS receivers usually pass a leap second announcement on to other software like the NTP daemon (ntpd).

The NTP daemon in turn forwards the leap second announcement to the operating system it is running on, which applies the leap second to its system time at the correct point in time.

Unless leap second smearing has been configured, ntpd also forwards the leap second announcement to its clients.

Leap seconds are preferably scheduled for the end of June or the end of December. Only if that shouldn't be sufficient, other potential dates would be the end of March or the end of September, and only if even more corrections needed to be applied a leap second could be scheduled for the end of any month.

However, past leap seconds have only been scheduled for the end of June or December, and according to the IERS this is not going to change in the foreseeable future.

So some systems or applications that have to handle leap seconds may do some plausibility checks and may only accept leap second announcements for specific dates.

Therefore, it is advisable to use only June 30 or December 31 for leap second tests.

Beside the leap second announcement from GPS there may be other sources that provide leap second information.

For example, ntpd may have been configured to evaluate a leap second file, and unless the leap second file has expired or is invalid, the information from a leap second file overrides the information from other sources.

So ntpd only accepts a leap second announcement from a GPS receiver if no leap second file is being used, or if the leap second file provides the same information as the GPS receiver.

If a valid leap second file and a GPS receiver provide different information then this may result in strange behavior.

If a real leap second announcement has been issued then the real date for which the leap second has been scheduled should be used for the test.

If no real leap second has been scheduled, the announcement has to be faked for the test. The easiest way to do this is to use the last real leap second date for the test.

In both cases it is not required to compute the GPS week number and day number at which the leap second will occur and if ntpd and a leap second file are involved, a current version of the file already has a valid entry for that leap second.

If there is no announcement of an upcoming leap second then for a future leap second date a leap second file had to be updated. This means a new leap second entry had to be added to the file, which requires computation of an NTP time stamp corresponding to the new leap second date.

Also, the file's expiration date had to be changed beyond the leap second date, and finally a new, valid hash had to be computed and added to the file.

Alternatively the leap second file could just be removed or renamed, so it can't be used by ntpd.

— Martin Burnicki martin.burnicki@meinberg.de 2019-06-06