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. -chris
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.