[tz] Leap seconds puzzle
Chris.Walton at telus.com
Wed Apr 8 22:47:51 UTC 2015
If you don't run ntpd with the "-x" flag, or if you have a broken version of ntpd that does not properly honour the "-x" flag,
then ntpd will tell the kernel (in advance) that a leap second will occur at midnight UTC time.
It is then up to the kernel to deal with the leap second. Different kernels may behave differently.
My testing on recently patched versions of RHEL_6 and Solaris_10 shows that the clock does go backwards.
This is the output of a script that is set to spit out the time every 500ms:
Jun 30 2015 23:59:57.398
Jun 30 2015 23:59:57.898
Jun 30 2015 23:59:58.398
Jun 30 2015 23:59:58.898
Jun 30 2015 23:59:59.398
Jun 30 2015 23:59:59.898
Jun 30 2015 23:59:59.399 <-clock jumps backwards here
Jun 30 2015 23:59:59.899
Jul 01 2015 00:00:00.399
Jul 01 2015 00:00:00.899
Jul 01 2015 00:00:01.399
Jul 01 2015 00:00:01.899
Jul 01 2015 00:00:02.399
Jul 01 2015 00:00:02.899
If you run a non-broken version of ntpd with the "-x" flag, then ntpd will not warn the kernel of the upcoming leap second.
In this case, nptd will slew the clock to make up for the leap second. Maximum slew rate is 500ppm which means it will take a minimum of 33 minutes before the clock will be back in sync with UTC time.
> NTP is able to give the client advance warning of an upcoming leap second, and the client
> ntpd can do various more sophisticated stuff to try to "smooth out" the leap second, since
> having the clock stop for a second - or worse, for sub-second timestamps to go backwards
> by a second - is undesirable. More undesirable than having the clock be deliberately
> inaccurate (by less than a second) for an extended period.
More information about the tz