Are you ready for the leap second on 30 June 2015? These are uncommon – they happen on average about every 18 months' time but sometimes there can be several years' time between them. This one is a bit special. While they usually happen on 31 December, this one happens on 30 June, and instead of this one happening on a holiday or over the weekend, it’s happening on a non-holiday Tuesday. Put another way, usually most folks aren’t doing anything when the leap second happens. This time, half of the world will be awake and on a work day.

If you are interested in learning more about how NTP will behave, some choices you have, and some technical history around NTP and leap seconds, please keep reading. If you are interested in more general information about why we have leap seconds, see this article by Rob Seaman.

What should I do?

If you’re running ntpd, the Reference Implementation of NTP from Network Time Foundation which is running on many tens of millions of systems, what version is it?

The best version to be running is ntp-4.2.8p3, which will be released before the leap second scheduled for 30 June 2015. If you can’t get that version installed on time, we recommend ntp-4.2.8p2, which was released on 7 April 2015.

If you are running a version of ntp-4.2.6, why haven’t you upgraded yet?

Have you carefully examined the costs and benefits of running EOL’d software and compared those to the costs and benefits of running newer, supported software?

Take a look at the NTP Release Timeline and look at how many issues we have fixed in those releases. If you are running an older version of NTP that has been patched by your vendor, how many of the items that we have fixed in 4.2.8 have they fixed in the version you have? Do you want to go thru the list of something north of 1,000 items – possibly 3,000 items or even many more – to see if they resolve problems that are actually things you care about? There are people still running NTPv3 code out there, which is at least 20 years' old. We don’t even have a count of how many problems we’ve fixed since then.

What has changed in NTP’s leap second handling?

While leap seconds have been around for a while, most everybody was able to ignore them before 2000. Indeed, while RFC-1119, the NTPv2 specification published in September of 1989 talks about leap seconds, it’s not until RFC-1305, the NTPv3 specification published in March of 1992, that the NTP Protocol and Reference Implementation is able to pass this information around.

In 1992, reference clocks and software didn’t really know about leap seconds. So the (totally reasonable) approach was taken: If an upstream time source tells you there is a leap second, believe it, and pass this information along to anybody who asks.

This worked really well for a while. But then, problems appeared because there was no way to easily override a false leap second warning. So in the NTPv4 specification, RFC-5905, and in NTF’s Reference Implementation of NTP, we do things a bit differently. Specifically:

• If there is a valid leap-second file, believe it.

• Otherwise, if we are getting time from a reference clock and it says there is a leap-second, believe it.

• Otherwise, if a majority of our sources of time say there is a leap-second, believe it.

These rules fit today’s reality much better.

How is the leap second applied?

This leap second should “appear” as the last second of June 30th, and the stroke of midnight into 1 July 2015 should happen “on the stroke of midnight”.

If you are running on a Unix system, your OS kernel should have the ability to keep time using NTP’s “kernel mode”, which just takes care if this for us. How this works is that at the last moment of the day, at 23:59:59.99, the kernel stops advancing the system clock for 1 second, thus inserting the leap second. At the end of this second, the clock runs normally again. It’s actually a bit more complicated than that – if the system is asked “what time is it” during this one second pause, the system clock is advanced by a tiny amount. This way, events can still be properly ordered. There is also a flag that is set that says “A leap second insertion is in progress.”

If the OS kernel does not have the ability to run in kernel mode, or if kernel mode is disabled for some reason, NTP runs in “daemon mode”. In this case, we’d ordinarily just set the clock back by one second. A bit brutal, but it’s the choice that usually sucks the least. Usually. However there are some applications that cannot tolerate the time moving backwards. In this case, NTP will make gradual adjustments to the system time, applying the leap second over the next 33 minutes and 20 seconds (2000 seconds' time). This sucks too, because during that interval the system clock is wrong. But at least time is always moving forward, pretty evenly.

What next?

If you have questions please let us know.

Is Network Time important to you? What about NTP, the protocol or our reference implementation? I’d bet the answer is a clear YES! to the vast majority of the population on the planet, so please help us to help you: join an NTF Consortium or make a donation and support NTP and NTF!