1 July 2012.
There was a leap second inserted at the end of June 2012 in UTC (the second before 1341100800 Unix epoch, which is 3550089600 NTP epoch). I watched it happen on several different systems, all of which sync time using ntpd.
Linux, no leapfile
This system is synced to timeservers which are advertising the leap second, but it does not have its own leapfile.
In 2012, I got the leapfile from ftp://tycho.usno.navy.mil/pub/ntp/.
In 2015, I used ftp://time.nist.gov/pub/leap-seconds.3629404800
ntpd variables before the event:
$ ntpq -c rv associd=0 status=4615 leap_add_sec, sync_ntp, 1 event, clock_sync, version="ntpd 4.2.6p5@1.2349-o Sat May 12 09:54:55 UTC 2012 (1)", processor="x86_64", system="Linux/3.2.0-2-amd64", leap=01, stratum=3, precision=-23, rootdelay=188.939, rootdisp=125.721, refid=163.73.58.221, reftime=d399a552.23661694 Sun, Jul 1 2012 2:18:26.138, clock=d399a644.106215cf Sun, Jul 1 2012 2:22:28.063, peer=60722, tc=7, mintc=3, offset=-8.826, frequency=27.933, sys_jitter=11.106, clk_jitter=10.861, clk_wander=3.028
I ran a simple program that prints CLOCK_REALTIME and CLOCK_MONOTONIC every 0.1 secs:
1341100797.965 74545.296 1341100798.065 74545.396 1341100798.165 74545.496 1341100798.265 74545.596 1341100798.365 74545.696 1341100798.465 74545.796 1341100798.566 74545.896 1341100798.666 74545.996 1341100798.766 74546.096 1341100798.866 74546.196 1341100798.966 74546.297 1341100799.066 74546.397 ← 799 starts 1341100799.166 74546.497 1341100799.266 74546.597 1341100799.366 74546.697 1341100799.466 74546.797 1341100799.566 74546.897 1341100799.666 74546.997 1341100799.766 74547.097 1341100799.867 74547.197 1341100799.967 74547.297 1341100799.067 74547.397 ← 799 replays! 1341100799.167 74547.497 1341100799.267 74547.598 1341100799.367 74547.698 1341100799.467 74547.798 1341100799.567 74547.898 1341100799.667 74547.998 1341100799.767 74548.098 1341100799.867 74548.198 1341100799.967 74548.298 1341100800.067 74548.398 ← 800 1341100800.168 74548.498 1341100800.268 74548.598 1341100800.368 74548.698 1341100800.468 74548.798 1341100800.568 74548.899 1341100800.668 74548.999 1341100800.768 74549.099 1341100800.868 74549.199 1341100800.968 74549.299 1341100801.068 74549.399
To the best of my understanding, the above is the "correct" POSIX handling of the leap second - the last second before midnight is replayed.
dmesg says:
[74498.634819] Clock: inserting leap second 23:59:60 UTC
(I'm not sure why it's 74498 instead of 74547. The kernel log is uptime and CLOCK_MONOTONIC returns something else?)
ntpd variables after the event:
$ ntpq -c rv associd=0 status=061b leap_none, sync_ntp, 1 event, leap_event, version="ntpd 4.2.6p5@1.2349-o Sat May 12 09:54:55 UTC 2012 (1)", processor="x86_64", system="Linux/3.2.0-2-amd64", leap=00, stratum=3, precision=-23, rootdelay=33.145, rootdisp=175.777, refid=6.15.154.237, reftime=d39a49b9.f4d6c58c Sun, Jul 1 2012 13:59:53.956, clock=d39a4c69.7ad513bc Sun, Jul 1 2012 14:11:21.479, peer=60716, tc=10, mintc=3, offset=0.104, frequency=14.249, sys_jitter=2.417, clk_jitter=3.037, clk_wander=0.626
Linux again
The second Linux system, a VPS, was configured very much the same as above but syncing against different upstream servers. It behaved the same as above but its peers had some trouble. Before the event:
$ ntpq -p
remote refid st t when poll reach delay offset jitter
==============================================================================
*clock.sjc.he.ne .CDMA. 1 u 320 1024 377 0.912 0.249 0.156
+clock.nyc.he.ne .CDMA. 1 u 171 1024 377 71.371 0.218 0.017
+clock.fmt.he.ne .CDMA. 1 u 959 1024 377 0.818 0.198 0.293
-li4-205.members 66.220.9.122 2 u 186 1024 377 0.572 0.846 0.384
support.rccfo.c 216.218.254.202 2 u 170 1024 377 0.909 -0.003 0.457
After the event:
$ ntpq -p
remote refid st t when poll reach delay offset jitter
==============================================================================
+clock.sjc.he.ne LOCAL(0) 4 u 322 1024 377 0.879 0.059 0.143
clock.nyc.he.ne .STEP. 16 u 182 1024 376 71.325 999.728 0.061
+clock.fmt.he.ne LOCAL(0) 4 u 958 1024 377 0.991 0.144 3.386
+li4-205.members 132.239.1.6 2 u 386 1024 377 0.638 0.205 0.151
*support.rccfo.c 69.25.96.13 2 u 358 1024 377 0.753 0.261 0.186
FreeBSD, with leapfile
Like the first system, this one is also synced to timeservers advertising the leap second, and also has its own local leapfile.
Before the event:
$ ntpq -c rv assID=0 status=4619 leap_add_sec, sync_ntp, 1 event, event_9, version="ntpd 4.2.6p5@1.2349-o Sat Jun 30 14:44:34 UTC 2012 (1)", processor="amd64", system="FreeBSD/9.0-RELEASE-p3", leap=01, stratum=3, precision=-20, rootdelay=18.933, rootdisp=209.430, refid=130.102.2.123, reftime=d399a5ab.1d01fbcb Sun, Jul 1 2012 2:19:55.113, clock=d399a61f.012f5c51 Sun, Jul 1 2012 2:21:51.004, peer=4026, tc=8, mintc=3, offset=-1.159, frequency=-7.155, sys_jitter=0.270, clk_jitter=3.504, clk_wander=0.037, tai=34, leapsec=201207010000, expire=201212280000
The moment of truth:
1341100797.921 218154.218 1341100798.022 218154.319 1341100798.123 218154.420 1341100798.224 218154.521 1341100798.325 218154.622 1341100798.426 218154.723 1341100798.527 218154.824 1341100798.628 218154.925 1341100798.729 218155.026 1341100798.830 218155.127 1341100798.931 218155.228 1341100799.032 218155.329 ← 799 starts 1341100799.133 218155.430 1341100799.234 218155.531 1341100799.335 218155.632 1341100799.436 218155.733 1341100799.537 218155.834 1341100799.638 218155.935 1341100799.739 218156.036 1341100799.840 218156.137 1341100799.941 218156.238 1341100799.042 218156.339 ← 799 replays 1341100799.143 218156.440 1341100799.244 218156.541 1341100799.345 218156.642 1341100799.446 218156.743 1341100799.547 218156.844 1341100799.648 218156.945 1341100799.749 218157.046 1341100799.850 218157.147 1341100799.951 218157.248 1341100800.052 218157.349 1341100800.153 218157.450 1341100800.254 218157.551 1341100800.355 218157.652 1341100800.456 218157.753 1341100800.557 218157.854 1341100800.658 218157.955 1341100800.759 218158.056 1341100800.860 218158.157 1341100800.961 218158.258 1341100801.062 218158.359
I couldn't find any mention of the leap second in the system logs.
FreeBSD, leap smear
This system is interesting because it's synced only to Google time servers, which "smear" the leap second over a 24-hour period. There's an interesting article describing the leap smear.
Variables before the event don't show a coming leap second:
$ ntpq -c rv assID=0 status=0644 leap_none, sync_ntp, 4 events, event_peer/strat_chg, version="ntpd 4.2.4p5-a (1)", processor="amd64", system="FreeBSD/9.0-RELEASE", leap=00, stratum=3, precision=-20, rootdelay=158.435, rootdispersion=449.770, peer=57767, refid=216.239.32.15, reftime=d399a5b2.e545f3ab Sun, Jul 1 2012 2:20:02.895, poll=6, clock=d399a63c.e0414a61 Sun, Jul 1 2012 2:22:20.875, state=4, offset=7.909, frequency=-5.790, jitter=29.121, noise=2.796, stability=0.018, tai=0
And realtime doesn't step backwards:
1341100797.927 506761.306 1341100798.028 506761.407 1341100798.129 506761.508 1341100798.230 506761.609 1341100798.331 506761.710 1341100798.432 506761.811 1341100798.533 506761.912 1341100798.634 506762.013 1341100798.735 506762.114 1341100798.836 506762.215 1341100798.937 506762.316 1341100799.038 506762.417 ← 799 1341100799.139 506762.518 1341100799.240 506762.619 1341100799.341 506762.720 1341100799.442 506762.821 1341100799.543 506762.922 1341100799.644 506763.023 1341100799.745 506763.124 1341100799.846 506763.225 1341100799.947 506763.326 1341100800.048 506763.427 ← 800 1341100800.149 506763.528 1341100800.250 506763.629 1341100800.351 506763.730 1341100800.452 506763.831 1341100800.553 506763.932 1341100800.654 506764.033 1341100800.755 506764.134 1341100800.856 506764.235 1341100800.957 506764.336 1341100801.058 506764.437