UTC Leap second: (nearly) all you need to know

· The PTP Guy

Table of Contents

2025 update #

Wow, it's been nearly ten years since I wrote this. I've now revived the site and moved away from Logdown since Logdown died while I wasn't watching. The article needs some updates, but still mostly holds up. Hopefully (and I tend to say this a lot, to no effect), hopefully I'm going to refresh it at one point.

Author's note #

This article is meant as a mostly non-scientific source of information about the leap second event in relation to running (maintaining) computer systems - personal computers, servers, network equipment or any other systems using some form of external time source. While I only managed to put this together just about a week before this year's event (2015), I thought it's still worth it as it is quite likely that this is not the last leap second event we are going to witness. If you're reading this before this year's event, consider it a good refresher. If you're reading this before this year's event and it's all new to you, you may be slightly worried. There is still some time.

I think it's worth adding that I was tired of reading oversimplified statements like "every now and then the day becomes longer by a second" being the only meaningful fact conveyed in a two-page long blob of text. I wanted to provide something in the middle. I probably failed (in favour of too detailed), but at least one cannot say I didn't try. As you will find, the style this is written in, is an annoying combination of technical details interleaved with absolute basics. This text also is not a ready-to-eat HOWTO. If you're looking for information on how to configure your NTP or PTP, this is not the right place - but keep checking the site for more articles. This is a knowledge transfer dump about all things leap second. Perhaps an infographic or a leap second timeline could be added at some point.

There are no graphics throughout, so I'll start with a picture. Here is the Leap Second 2015 in stereotypes:

theptpguy_leap_second_jun15.jpg

In the above picture we have a stereotypical Frenchman (beret, moustache and all) of Le IERS, by means of a slingshot injecting a leap second into a GPS satellite, which then shoots it back in the direction of our stick character wanting to catch it. This character, slightly reminiscent of Fido Dido minus the hair, is you. On the left hand side we have a number of protesters occupying the building of an NMI. The most prominent figure on top of the roof with the "leap second must go!" placard, has ITU written on his top. Clear? It should be mostly clear once you've read section 1. And partially section 2.

Section 1. of this text presents the theory behind the Leap Second, while Section 2. is all about practice and implementation.

To any fellow time nuts potentially reading this: this text contains some simplification and could be clarified in certain areas - I'm aware.

Section 1: the theory #

UTC and other scientific time scales #

For different purposes, many time scales and time standards are maintained around the world, and many of them are closely related. It is sufficient to say that the Coordinated Universal Time (UTC) is the time to which the world regulates its clocks. UTC is being locally corrected by a certain amount of hours depending on geographically aligned time zones, and this offset, along with the optional daylight saving correction back or forth by another hour, constitutes your local time - wall clock time. It is very, very probable that the clock that your computer's operating system maintains in the background, runs in UTC.

UTC is one of the successors of the Greenwich Mean Time (GMT). GMT was a natural, solar time scale (according to which, roughly, it was noon when the sun crossed the 0° longitude - where the Greenwich observatory is). Roughly, hence mean time. This mean time today is being calculated based on the observation of the moon and other celestial bodies - and that is UT1, the current scientific solar time standard based on the rotation of Earth.

UT1 dynamically follows Earth's rotation, speed, orbit, axial tilt and other factors determining when Earth finds itself at a certain rotation or position in relation to the Sun. Very simply put, if as a result of some event the duration of Earth's day were to become longer by an hour, UT1 would still be in line with Sun's movement on the horizon, and therefore the "new" UT1 second would likely need to be 1/24th longer than the previous second. While UT1 is being tracked by the International Earth Rotation and Reference Systems Service, it is safe to say that "perfect" UTC remains unchanged (OK, UTC is in fact based on time negotiated/averaged amongst National Metrology Institutes around the globe, TAI, but this is by nanoseconds - just pretend you did not read this). UTC remains unchanged up to a point. Luckily the variations in Earth's rotation are not significant enough to cause any visible changes for Earth's inhabitants, but UTC and UT1 do eventually diverge. If UT1 were to diverge from UTC by a second every year (plus or minus one second) and UTC was never corrected, in thirty-six centuries the sun would cross the 0° meridian at 11AM or 1PM. We do not want this to happen - do you see where this is going?

The leap second event #

Since 1972, the fractional part of the UTC second follows another time scale, which is the International Atomic Time (TAI). TAI is a coordinated time scale describing proper time along the world line, that is time influenced by relational physics - the speed of Earth, gravity field etc. - and not Earth's movement in relation to Sun's position, unless in connection with Sun's gravity.

To stay in line with solar time, UTC time has to be corrected, but since this is the world's main time scale, it is not to be dragged back and forth like UT1. The use cases and importance of TAI and UT1 justify those adjustments - and complex physics research can yield unexpected results because of time differences. Major UTC corrections are kept to a minimum, and so those are made only periodically, and with a fairly long notice. So, UTC is in line with TAI, but when required, it is corrected by a whole number of seconds based on its relation to solar time - UT1. When UT1 diverges from UTC by more than 0.9 seconds in either direction, a decision is made by the IERS to make a one-second correction to UTC, and that will be the leap second. Since the start of UTC there have been multiple of those, and the initial TAI to UTC offset in 1972 was 10 seconds. Although there are provisions for introducing negative leap seconds, we are yet to witness one. So far we have not had a single negative leap second.

When the decision for the next period is known, the IERS in their semi-annual Bulletin C, announce the coming of a leap second - or not - within the next semester (See IERS Bulletins). Bulletin C is released every six months regardless of those events, and will state that on the next last day of June or last day of December, either a second will be added or deleted, or that nothing will happen. Typically the bulletin is released somewhere between five and six months before the next event. The event happens at midnight, on 30th of June or on 31st of December. When a leap second is inserted like it usually is (i.e. not deleted), the last minute of the leap second day lasts one second longer. This final timestamp is represented as 23:59:60 UTC and it is an approved representation of UTC time. Most applications don't even support displaying this.

OK, this sums up the theoretical part... nearly.

Time provider and time reference #

Now we know what happens, when and who decides that the leap second will or will not happen on the given 30th of June or 31st of December. But how do all the systems around us know about this? How does your desktop if you have one, your laptop, three smartphones, two tablets, your smart TV, your Raspberry Pi, your GPS receiver, and your home network attached storage server all know about this?

All of those systems use some protocol to synchronise the time. GPS also transmits time, and so does the mobile network. Every device will use some protocol to synchronise its time with an upstream source. This could be NTP, PTP, positioning systems like GPS, it could be IRIG, GSM or CDMA. IRIG, PTP and NTP are dedicated timing protocols while the others only include timing information as part of the service.

Some of those (time) protocols have direct support for indicating the leap second events to the client (your device), and some do not. But what they all have in common is that regardless of the type of remote station or device used to provide time to a client, this remote station - time server or transmitter - this time provider must also synchronise its own time with some reference. There is actually a finite number of types of precision time reference sources available. This reference could be:

The most common scenario is that your computer device will use an NTP (or recently also PTP) server, and that server in turn will know the time from GPS satellites, or from another, better, server. In most cases, the ultimate time source in user's control will be GPS, which is in line with UTC. If you look at the hierarchy of time delivery from the topmost provider to your end device, UTC is at the very top of this hierarchy. And this means that the time on your device is Traceable to UTC.

So GPS knows the time? Well yes. In fact this is how a GPS receiver knows its position in the first place. And also, GPS supports leap second information. When I say GPS, I mean GPS, GLONASS, Gallileo, Beidou or any other positioning system. I will use GPS as the main example, but others are similar. So it's GNSS in general, not just GPS. Now, different types of GPS receivers exist, they can all receive time, but some are specialised timing receivers, geared towards precision timing, and less so positioning. Those receivers are often integrated in NTP or PTP servers, which provide time to computers or, for example, GSM base stations.

Oh no, more time scales! #

What exactly happens after the Bulletin C is released by the IERS and the verdict is a yes? The people who run GPS (See GPS governance) immediately update the satellites with this information, and from that moment, any GPS receiver will be made aware of the coming of the leap second. How is this information organised?

GPS itself must also use some time scale. Does it use UT1? No. Does it use UTC? Well, it once did. Once. GPS time started at midnight on 6th of January 1980. This is the GPS epoch and at that starting point it was based on UTC. GPS time is monotonic, so is not subject to the leap seconds. Because most applications use UTC, the GPS satellites transmit the GPS time along with UTC to GPS offset in seconds. Just to clarify, out of the other satellite-based positioning systems, more or less half uses an epoch and offset like GPS, and the other half uses UTC.

The International Atomic Time (TAI) mentioned earlier is also monotonic. In 1972, TAI was exactly 10 seconds apart from UTC, and by the time GPS started, UTC to TAI offset was exactly 19 seconds. Today, that is before the end of June 2015, the current UTC to TAI offset is 35 seconds and is about to become 36 seconds. UTC to GPS offset however is 16 seconds, and will become 17 seconds.

GPS time is transmitted as week number and number of seconds within the week. The UTC information inside GPS frames consists of: current UTC offset, week number of next change, day number of next change and the next value. Based on this, any GPS receiver knows exactly if and when the leap second event happens.

Section 2 - operational matters and practice #

Operating System - what happens #

Before I explain how two widely known time synchronisation protocols implement the leap second information, I'm going to touch on how the OS deals with the leap second.

To get the easy stuff out of the way - Windows does nothing about it. The internal timekeeping subsystem used in Windows has no special provisions for inserting or deleting the leap second. It relies on a time service like NTP to correct the time - so during the event, nothing happens, the time is corrected on next sync (information exchange) with the time server, which could even be up to multiple minutes after midnight. Well, that's pretty boring, but this also means it's quite likely that multiple Windows systems may be out of sync with each other for a couple of minutes after the event.

I think it's fair to say that most of the world's other operating systems are either variants of UNIX, were derived from UNIX like the BSD family (on which Mac OS X is based), or were modelled after UNIX (like MINIX, which in turn was an important influence in creating Linux). There are also realtime, embedded and industrial operating systems like QNX, ucLinux or FreeRTOS. They are all UNIX-like, implement the POSIX standard at least partially and provide similar Command-Line Interfaces (CLI). Many of these systems implement the NTP API, which means they use a common way of dealing with leap seconds.

There is another time scale that is used by computer systems, and that's UNIX time - it is based on UTC, started at the start of day on the first of January 1970, and is maintained by the computer system as a counter: number of seconds since that day (UNIX time epoch). Simple. Your non-Windows computer system's clock likely runs in UNIX time, and only when displayed using functions making corrections for your local time zone, gives you your wall clock time. There is also a sub-second counter, which typically counts nanoseconds (billionths of a second).

To insert or delete the leap second, some time synchronisation software must tell the operating system about the coming of this event - read on to find out more about how this information is distributed by different protocols. Unlike with GPS which has the information for months in advance, using the NTP API one can only inform the system about the leap second event during the last 24 hours, and this is because this information is only passed as either of two flags: STA_INS or STA_DEL. As soon as one of those flags is set in the operating system, its timekeeping subsystem is aware that the leap second happens at next midnight.

When midnight comes and the STA_INS flag is set, the last minute must last one second longer. In order to achieve this, the last second is repeated twice (using Linux as an example): 23:59:59.999999999 changes to 23:59:59.000000000 again (at that point the displayed time should be 23:59:60). If STA_DEL is set (has not happened yet), 23:59:58.999999999 transitions straight to 00:00:00.000000000. That is it. This is all there is to it. The STA_INS or STA_DEL flags are cleared immediately, and life goes on. Any different implementation of the leap second would do this in a similar manner - that is, if the implementation supports stepping the time.

Newer implementations of the NTP API allow setting the TAI to UTC offset in kernel for applications which need TAI time, and also more recently, TAI based time (rather than UTC/Unix) is being introduced as an option for running the OS clock. The advantage is that TAI is monotonic, so the only thing that changes during the leap second event is the TAI to UTC offset. Some applications, especially security applications, do not like when time steps backwards - which is what happens in Linux when the last second is repeated twice on leap second insertion.

Disseminating the leap second information - and another time base #

In the "Oh no, more time scales!" section I explained how GPS transmits the leap second information. Now I will explain how two network time protocols and one digital timecode protocol do this. I will start with NTP.

Network Time Protocol - NTP #

NTP is by far the most commonly used network time synchronisation protocol in the world. NTP, (quelle surprise!), uses its own time base. It is similar to UNIX time, and follows UTC, but uses a different epoch (starting point). The NTP seconds counter starts at the beginning of the 20th century - year 1900. NTP uses the two-bit Leap Indicator (LI) field to convey the leap second information - first field in the packet:

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |LI | VN  |Mode |    Stratum     |     Poll      |  Precision   |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                         Root Delay                            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                         Root Dispersion                       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                          Reference ID                         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      +                     Reference Timestamp (64)                  +
      |                                               +++++++++++++++++
      |               ++++++++++++++++++++++++++++++++
      |    +++++++++++    O,/ _ _ _ _ _ _ _ 
      +-+-+               o`\   SNIP

Being two-bit, the Leap Indicator can have four values:

           +-------+----------------------------------------+
           | Value | Meaning                                |
           +-------+----------------------------------------+
           | 0     | no warning                             |
           | 1     | last minute of the day has 61 seconds  |
           | 2     | last minute of the day has 59 seconds  |
           | 3     | unknown (clock unsynchronized)         |
           +-------+----------------------------------------+

The rest is quite simple. Once the client receives the LI field and it's not at value 3 (binary 11), it has the required information to react - this being either do nothing or set the respective STA_INS or STA_DEL flag in the OS kernel. OK, that is all - provided that the client trusts the NTP server - and NTP puts a lot of effort into establishing if it's OK to trust an NTP server, but that's outside the scope of this text. As the leap second event happens, the NTP timestamp is actually changed by plus or minus one second. This means that NTP time is not monotonic, just like UTC.

One crucial precaution is ensuring that the NTP client, and especially the NTP server, receives this information well in advance. NTP algorithms establish ideal polling intervals which can be minutes long. If the NTP server starts sending out the leap second information too late, a client may not receive it in time, and if it misses it, it will never see it since it's gone from the server after midnight - and that client will end up with a one-second time difference after the event. Also on the way from the topmost NTP server to the client there may be a chain of NTP servers synchronised with each other - different NTP strata (layers). It takes a while for the leap second information to seep through the whole hierarchy from top to bottom - therefore it is of utmost importance that whatever technology is used to synchronise the topmost NTP server, it informs this NTP server about the leap second event as early in the leap second day as possible.

An NTP server with a GPS reference needs to recognise the day of the event and turn the GPS UTC parameters information into the correct Leap Indicator field value on the correct day. An NTP server with an NTP reference forwards the LI field values based on its own clock's information, which was populated by the upstream NTP.

Precision Time Protocol - PTP #

As the number of applications requiring very precise time (precisely aligned with reference time) grows, Precision Time Protocol, the IEEE 1588 standard, is gaining popularity outside of its original areas such as instrumentation and measurement and then Telecom. This is not to say that NTP cannot achieve good precision, but let's just say that most NTP implementations do not achieve it and leave it at that - for now.

PTP was designed with scientific and measurement applications in mind, and, for a change, does not use a new time scale or time base. Native PTP time scale is the TAI time - which as we know is monotonic. PTP however also distributes UTC, by advertising the TAI to UTC offset in the currentUtcOffset field in its Announce message. OK, again this is a simplified statement - PTP may or may not use the PTP (TAI) time, but in most cases it does, so let's assume this option here.

As you have already learned, TAI time does not change with the leap seconds - the only thing that changes as the leap second event comes and goes, is the TAI to UTC offset. Well, not the only thing. In a similar manner to NTP, PTP also provides special flags which inform the client (slave in PTP terminology) that the event happens on the given day. The first and second bit of the second byte of the two-byte flagField in the PTP message header are two flag bits: leap61 and leap59. A software implementation translates those flags to STA_INS or STA_DEL in the operating system. Most hardware timing systems using PTP will sync themselves to TAI, so will not require any special action, and no time stepping is performed, only the UTC offset value changes. This is why often time sync hardware manufacturers do not realise that dealing with the leap second can be problematic - they often do not have to deal with what an operating system does to implement the leap second.

PTP distributes the leap second information in Announce messages, which tend to be sent out at much shorter intervals than what NTP would use, typically once per second or once per two seconds. This means that PTP systems should deal with leap second distribution in a much more robust manner than NTP. The IEEE 1588-2008 standard, which is the current version, states (clause 9.4) that the PTP server (Grandmaster or GM) shall start sending out the leap flags 12 hours before midnight, unless it learns about the leap second event later. Arguably there may be nothing wrong with sending out this information earlier, but this is what the standard states. If the PTP GM uses a GPS time source, it starts announcing leap seconds as per the standard. If it is a Boundary Clock however (BC), slave to an upstream GM and master to other slaves downstream, it simply re-advertises the parent GM's datasets, along with leap second flags.

IRIG timecode - IEEE 1344 extensions #

The IRIG timecode is a standard for time distribution using digitally coded electrical signals - typically using coaxial cable. It is a fairly old standard (dating from 1960), but still maintained - last revision is from 2004. Originally IRIG did not provide the interconnected device with any information about the leap second events. The first extension to allow this was part of the IEEE 1344 standard used in the power industry. The 1344 extensions finally found their way into the IRIG standard, but this mode of operation is still called IEEE 1344 by most manufacturers. Those extensions include leap second information and daylight saving time information. Bit 60 (LSP - Leap Second Pending when set to 1) and bit 61 (LS - Leap Second type: 0 = add, 1 = delete) convey the leap second information. Again, very similar to NTP and PTP. There is one major difference.

IRIG as a time source for NTP: don't #

One interesting fact about IRIG leap seconds, and often a source of problems, is that the LSP bit is in fact "Leap Second Pending at end of minute". This means that an IRIG receiver will only know about the leap second for one minute before midnight - but IRIG frames are sent at high rates: tens to thousands per second. This is not an issue if the connected receiver serves time to other devices also using IRIG, or maybe PTP, but it becomes an issue if we have an NTP server using IRIG as its time reference. In this case, the 60 seconds is usually barely enough for the IRIG-connected NTP server to accept the leap second information. In practice, having tested this with multiple IRIG-enabled systems, I noticed that the NTP server will start re-advertising the leap second information at least over 20 seconds into the last minute, typically about 30 seconds, leaving only 30 seconds for the rest of the NTP hierarchy to distribute it. It is almost guaranteed that this will fail. Bsed on pure statistics, different NTP servers and clients will poll at different times, and some will get the leap second information, but some will not. You end up with a mix of clocks with up to one second difference which may take a long, long time to finally agree with each other, and they will agree based on a majority vote, and the majority may actually be the ones which did not get the leap second information. The whole timing system ends up in a disarray, all because of the late arrival of the leap indicators thanks to IRIG.

Therefore, if you're using IRIG to feed time to your NTP server, for as long as the leap seconds are still being introduced, stop. Do yourself a favour and upgrade to GPS-based NTP servers and use GPS distribution amplifiers or splitters, or use PTP as the upstream time source if your time server supports this.

Manual leap seconds distribution - the leap seconds list file #

In the previous sections I described how the leap second information is distributed all the way from the atomic clocks down to your end device, and how in some conditions it is possible to miss the leap second information. Can anything be done about that, and moreover, can we do something about systems that sync very infrequently, or are isolated but still for some reason need to be made aware of the leap seconds? Internet (and US government) to the rescue! The Internet Engineering Task Force (IETF) - the body issuing the RFC documents, including the NTP standard, and the National Institute of Standards and Technology, United States' official time source, provide a text file, the leap seconds file. The leap seconds file is a standardised text file containing the information about the past and future leap seconds. The file contains: a validity timestamp, a checksum, and a list of all previous leap seconds including the very next one, expressed in NTP seconds at the time of the event, along with the TAI to UTC offset at that time. The leap seconds file is available via HTTP from the IETF: (correction since this was originally written - now hosted by IANA) - (https://data.iana.org/time-zones/data/leap-seconds.list) and should be available via FTP from NIST: (ftp://time.nist.gov/pub/).

NTPd, the de facto standard NTP implementation, was the first to support this file format, but in version 2.3.1 also PTPd gained support for parsing this file - 2015 version is bundled with the source. When this file is loaded by the software, the leap second information becomes readily available and the software can set the protocol fields and set the OS kernel flags immediately when the time comes. This can be used for offline operation, but can also supplement situations when the leap second information would have arrived from the time server too late.

Should I be afraid? Is this the new Year 2000 problem? Will my systems explode? #

Yes, yes and yes. No. No, no and no. What you should do however, if you maintain systems that will be subject to the leap second event, is to test. Test and test again. Test your applications and your operating systems to make sure there are no nasty surprises. What to use to test? If you want to test with NTP or PTP, you can use free software and the leap seconds file to simulate the leap second event and see how your clients and applications will behave, or ask your vendor if their hardware or software provides built-in testing functionalities or manual override.

You can only rest assured if you test every system you run - and that may include a time server using GPS as time source. Some of those will let you manually set the leap second information and send it to your clients, but this is not equivalent to the GPS receiver actually seeing the leap second event coming from the GPS satellites. This year I found an issue with one manufacturer's implementation, which could not have been identified without an actual GPS signal, and of which the vendor himself was not aware. All because of inadequate testing.

If you are using GPS as your time source, the only way to fully test your system is using a GPS simulator. I will not recommend a vendor, but there are multiple vendors providing them today. A GPS simulator will physically output a (synthesised) radio frequency (RF) signal looking no different to a valid GPS satellite signal. A GPS receiver connected to such a simulator will behave as if it is connected to a regular antenna. If your simulator's manufacturer allows you to set the time and UTC parameters, or provides you with a playback file for the leap second events, you are in a good position to fully test your leap second readiness. Yes, you do have to trust the simulator's manufacturer.

During the previous event, in 2012, we have seen many reports of servers crashing and sites going down as a result of the leap second event, like This one on WIRED with a lovely tabloid-like title. If you ask me, this is only due to lack of adequate testing. OK, it was caused by the leap second, but this does not mean it is the embodiment of all evil. What about the DST time, should we get rid of that as well?

What is the future of leap seconds - are we expected to see them forever? #

There are many voices suggesting that the leap seconds should be abolished because they cause too many issues. Warning: subjective, personal opinion: my opinion is that this is akin to abolishing "apostrophe's" (apostrophes!), because they are "confusing". On the other hand, I am not the one to decide. The International Telecommunication Union is to make a recommendation in 2015 as per this question: http://www.itu.int/pub/R-QUE-SG07.236-1-2014, and also conferences like this happen - Future of UTC. So far, Business As Usual and we have another leap second coming soon. All we can do is deal with it.

Is there an alternative approach? #

There is more than one alternative approach which can make it easier for applications to "swallow" the leap second, but on the other hand, those alternative approaches result in loss of UTC compliance, if one cares about that - and many do.

The do nothing approach #

If your time synchronisation software provides this option, you may choose to ignore the leap second event. PTPd and Chrony support this directly, and NTPd can support this if you fiddle with configuration and the leap seconds file. With this approach, you tell the kernel nothing about the approaching leap second, despite the server announcing it. The client ends up with a 1-second offset after midnight and gradually slews it back to near-zero afterwards, or steps it if the offset is marginally greater than 1 second. Just like Windows would do it. This is reasonably hassle-free, but in the period after midnight, it will take a longer while to re-sync the clock. A typical Linux or Unix clock can only shift the clock by 512 ppm (parts per million), that's half a millisecond per second. This gives you about 40 minutes before the clock is stabilised again - but Chrony for example, and ptpd, can do this in less time.

The Leap Second smear - Google's approach #

In 2011, before the previous leap second event, Google revealed their take on the leap second event - the leap second smear. It is definitely an interesting approach. What this solution does is it silently introduces the ± extra second during the last day, spread along multiple hours. To insert or remove one second during 24 hours, every second only has to be made longer (or shorter) by 11.5 microseconds - that's 11.5 millionth of a second. If this is done, then at the moment of the leap second, the clock is already where it should be after the event, and the artificial offset is simply taken off. When that happens, the clock correction is off by 11.5 parts per million, so that has to be immediately removed.

This approach can be implemented either in the client or in the server - where a client implementation allows the server to simultaneously support regular clients and those using the leap second smear. PTPd and Chrony can both do it.

Are there any other options? Should I adopt an alternative approach in my systems? #

Another option is to step the time after the event without using the OS leap second mechanism. This may be better or worse for your application. Ultimately it is up to you which way you choose to deal with this; you only need to review the implications. If all you care about is sync within your equipment, the alternative solutions may be a good idea to make things go smoothly. If you exchange timestamped information with the outside world, you may want to stick to UTC and deal with the leap seconds the official way. Whatever you do, test it. Test it twice, test it tenfold.

Ending comments #

So there you have it, a Leap Second knowledge transfer pack. Now that this has been written, I will try to refresh it every now and then to keep it up to date. I hope it proves useful. I simply can't wait to hear this year's horror stories.

Edit: No horror stories that year, all went smoothly at work and the world at large did not collapse either. Clearly we are able to deal with leap seconds now without major issues.

Written at 0° 0' 22" longitude.

#utc #leap #second #leapsecond #faq #smear #gps #gnss