Today the 34th leapsecond will be inserted in ‘our time’ by adding a 60th second in the last minute of this year.
This was announced by the International Earth Rotation and Reference System Service (IERS) in July this year.

Dr. Daniel Gambis, director of the Earth Orientation Centre, explains precisely why insertion of leapseconds is necessary.

Of course I wanted to see whether my NTP servers followed this procedure. In August I downloaded the official leapsecond file and added it to my ntp.conf. This means that when you do not have a time reference capable of announcing leapseconds, this file informs ntpd accordingly.

Today around 01.00 local time (00.00 UTC) ntpd informed itself about the insertion of a leapsecond:

ntp.remco.org (FreeBSD):
31 Dec 00:59:46 ntpd[778]: crypto: leap epoch 1.0 days
31 Dec 01:00:02 ntpd[778]: kernel time sync status change 2117
31 Dec 01:00:02 ntpd[778]: crypto: leap epoch 1.0 days

ntpdc -c kern for this machine yields:
remco@time [/home/remco]> ntpdc -c kern freebsd
pll offset:           -6.7e-08 s
pll frequency:        -50.244 ppm
maximum error:        0.000236 s
estimated error:      1e-06 s
status:               2117  pll ppsfreq ppstime ins ppssignal nano
pll time constant:    4
precision:            1e-09 s
frequency tolerance:  496 ppm
pps frequency:        -50.244 ppm
pps stability:        0.003 ppm
pps jitter:           1.026e-06 s
calibration interval: 256 s
calibration cycles:   2869
jitter exceeded:      1383
stability exceeded:   0
calibration errors:   3

ntp2.remco.org (LinuxPPS):
31 Dec 00:59:53 ntpd[22455]: crypto: leap epoch 1.0 days
31 Dec 01:00:09 ntpd[22455]: kernel time sync status change 2011
31 Dec 01:00:09 ntpd[22455]: crypto: leap epoch 1.0 days

where ntpdc -c kern outputs:
remco@time [/home/remco]> ntpdc -c kern ntp2
pll offset: 1.017e-06 s
pll frequency: 5.571 ppm
maximum error: 0.00775 s
estimated error: 7e-06 s
status: 2011 pll ins nano
pll time constant: 4
precision: 1e-09 s
frequency tolerance: 500 ppm

DCF77 transmits leapsecond information, as can be seen in the logfile after restarting ntpd on a machine which has no leapsecond file:

31 Dec 11:19:45 ntpd[20791]: PARSE receiver #0: interval for following error message class is at least 00:01:00
31 Dec 11:19:45 ntpd[20791]: PARSE receiver #0: no data from device within poll interval (check receiver / wiring)
31 Dec 11:20:03 ntpd[20791]: synchronized to GENERIC(0), stratum 1
31 Dec 11:20:03 ntpd[20791]: kernel time sync status change 0001
31 Dec 11:21:55 ntpd[20791]: kernel time sync status change 0011

So at least I now know that ‘I am in time’ with my leapseconds! :- )

Update Jan 1st 2009:

Yesterday friends and family asked me: “What are the effects of not heeding the leapsecond insertions, anyway, when it is so important, why don’t we hear about it in the news?” My answer was: “Wait until tomorrow, then you’ll hear and read enough”.  Some URLs:

But the most intriguing discovery I just made was that the Russian Institute of Metrology for Time and Space (IMVP/VNIIFTRI) did not insert the 34th leapsecond yesterday (!):

remco@lithium [/home/remco]> ntpdate -q ntp1.imvp.ru
server 62.117.76.142, stratum 1, offset 1.002066, delay 0.08249
1 Jan 13:49:14 ntpdate[27913]: step time server 62.117.76.142 offset 1.002066 sec

remco@lithium [/home/remco]> ntpdate -q ntp2.imvp.ru
server 62.117.76.141, stratum 1, offset 1.001125, delay 0.08253
1 Jan 13:29:45 ntpdate[27803]: step time server 62.117.76.141 offset 1.001125 sec

remco@lithium [/home/remco]> ntpdate -q ntp3.imvp.ru
server 62.117.76.138, stratum 1, offset 1.001030, delay 0.08250
1 Jan 13:29:50 ntpdate[27804]: step time server 62.117.76.138 offset 1.001030 sec

remco@lithium [/home/remco]> ntpdate -q ntp4.imvp.ru
server 62.117.76.140, stratum 1, offset 2.001320, delay 0.08302
1 Jan 13:30:04 ntpdate[27808]: step time server 62.117.76.140 offset 2.001320 sec <- 2s ??

I won’t draw any conclusions, but I fear the next satellite/space mission or rocket launch on Russian territory ; -)