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.965575218 74545.296276316
1341100798.065654847 74545.396355945
1341100798.165732010 74545.496433108
1341100798.265808710 74545.596509807
1341100798.365882367 74545.696583465
1341100798.465962539 74545.796663634
1341100798.566029926 74545.896731022
1341100798.666114877 74545.996815975
1341100798.766180628 74546.096881726
1341100798.866261332 74546.196962428
1341100798.966332238 74546.297033334
1341100799.066411386 74546.397112484 ← 799 starts
1341100799.166486318 74546.497187416
1341100799.266561421 74546.597262519
1341100799.366637390 74546.697338488
1341100799.466712025 74546.797413121
1341100799.566789153 74546.897490250
1341100799.666868637 74546.997569733
1341100799.766949230 74547.097650325
1341100799.867022710 74547.197723808
1341100799.967098540 74547.297799638
1341100799.067177014 74547.397878112 ← 799 replays!
1341100799.167254579 74547.497955678
1341100799.267331632 74547.598032731
1341100799.367408428 74547.698109524
1341100799.467485784 74547.798186881
1341100799.567557978 74547.898259076
1341100799.667640053 74547.998341151
1341100799.767711005 74548.098412103
1341100799.867786268 74548.198487369
1341100799.967865940 74548.298567041
1341100800.067945632 74548.398646732 ← 800
1341100800.168025947 74548.498727045
1341100800.268100940 74548.598802036
1341100800.368180188 74548.698881287
1341100800.468259249 74548.798960348
1341100800.568334326 74548.899035425
1341100800.668410638 74548.999111736
1341100800.768490677 74549.099191774
1341100800.868564369 74549.199265467
1341100800.968639266 74549.299340364
1341100801.068718729 74549.399419828

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.921659142 218154.218562039
1341100798.022663257 218154.319566154
1341100798.123662482 218154.420565379
1341100798.224662197 218154.521565094
1341100798.325663378 218154.622566275
1341100798.426660648 218154.723563056
1341100798.527655962 218154.824558859
1341100798.628662032 218154.925564929
1341100798.729652947 218155.026555844
1341100798.830660972 218155.127563380
1341100798.931665087 218155.228567984
1341100799.032661379 218155.329563787 ← 799 starts
1341100799.133670382 218155.430573279
1341100799.234662764 218155.531565661
1341100799.335665411 218155.632568308
1341100799.436662192 218155.733565089
1341100799.537674129 218155.834577026
1341100799.638664555 218155.935567452
1341100799.739670624 218156.036573522
1341100799.840662517 218156.137564925
1341100799.941666142 218156.238569039
1341100799.042661457 218156.339564354 ← 799 replays
1341100799.143665082 218156.440567979
1341100799.244661863 218156.541564760
1341100799.345665489 218156.642567897
1341100799.446662759 218156.743565167
1341100799.547664918 218156.844567326
1341100799.648658277 218156.945561174
1341100799.749666302 218157.046569199
1341100799.850668461 218157.147571358
1341100799.951670620 218157.248573517
1341100800.052658112 218157.349561009
1341100800.153666138 218157.450569035
1341100800.254660964 218157.551563860
1341100800.355671433 218157.652573841
1341100800.456661859 218157.753564756
1341100800.557671351 218157.854574248
1341100800.658662266 218157.955565163
1341100800.759651225 218158.056553633
1341100800.860666095 218158.157568991
1341100800.961641853 218158.258544750
1341100801.062671390 218158.359574287

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.927437489 506761.306520689
1341100798.028437170 506761.407520410
1341100798.129437571 506761.508520812
1341100798.230437253 506761.609520453
1341100798.331436774 506761.710519974
1341100798.432437255 506761.811520535
1341100798.533436936 506761.912520176
1341100798.634437337 506762.013520538
1341100798.735437139 506762.114520339
1341100798.836437020 506762.215520220
1341100798.937437581 506762.316520781
1341100799.038436622 506762.417519862 ← 799
1341100799.139436784 506762.518519984
1341100799.240437426 506762.619520666
1341100799.341442068 506762.720525308
1341100799.442439549 506762.821522149
1341100799.543436711 506762.922519951
1341100799.644436473 506763.023519713
1341100799.745436635 506763.124519835
1341100799.846436516 506763.225519757
1341100799.947437798 506763.326520358
1341100800.048436560 506763.427519760 ← 800
1341100800.149436802 506763.528520043
1341100800.250436325 506763.629519525
1341100800.351437607 506763.730520167
1341100800.452436249 506763.831519489
1341100800.553436331 506763.932519532
1341100800.654441813 506764.033525054
1341100800.755436896 506764.134520096
1341100800.856436738 506764.235519978
1341100800.957436740 506764.336519981
1341100801.058444503 506764.437527223