Many people don't know that approximately every 1.5 years there is typically a leap second inserted in the official time scale, typically at midnight UTC on June 30 or December 31.

The following is an ASCII capture of one such event as seen via a modem:

National Institute of Standards and Technology
Telephone Time Service, Generator 3B
Enter question mark "?" for HELP
D L D
MJD YR MO DA HH MM SS ST S UT1 msADV <OTM>
49533 94-06-30 23:59:58 50 1 -.2 045.0 UTC(NIST) *
49533 94-06-30 23:59:59 50 0 -.2 045.0 UTC(NIST) *
49533 94-06-30 23:59:60 50 0 +.7 045.0 UTC(NIST) *
49534 94-07-01 00:00:00 50 0 +.7 045.0 UTC(NIST) *
49534 94-07-01 00:00:01 50 0 +.7 045.0 UTC(NIST) *

The bold line represents a second which would not normally exist. The column labeled UT1 with values of -.2 and +.7 is basically the reason that we insert the leap second.   A friend told me that the UT1 change wasn't noted immediately by ACTS at 1998's leap second.

It is interesting to study how various precision time sources deal with leap seconds. Following is an ASCII capture of another modem service during the next leap second:

50082 365 235958 UTC
*
50082 365 235959 UTC
*
50083 001 000000 UTC
*
50083 001 000001 UTC
**
50083 001 000002 UTC
*

Notice how there was no report of 235960 and there was an extra "OTM" (*) at an unexpected point. I reported that to USNO. My friend tried to capture for me on the next leap second but was a couple seconds late to see the event (but at least we don't seem to see the same double-asterisk after 000001):

50630 182 000001 UTC
*
50630 182 000002 UTC
*
50630 182 000003 UTC

I kept busy during that same leap second (June '97). I captured it via modem from TUG (Austria), with the leap second shown on the bold line (and note that the warning text went away as desired):

1997-07-01 01:59:55 CEST 22718210260319970630235950629-5+060502!Leap Sec. on!*
1997-07-01 01:59:56 CEST 22718210260319970630235950629-5+060503! 1997-06-30 !*
1997-07-01 01:59:57 CEST 22718210260319970630235950629-5+060504==============*
1997-07-01 01:59:58 CEST 22718210260319970630235950629-5+060505Type 2 slashes*
1997-07-01 01:59:59 CEST 22718210260319970630235950629-5+060506 to stop code *
1997-07-01 01:59:60 CEST 22718210260319970630235950629-50000507and ? for help*
1997-07-01 02:00:00 CEST 22718210260319970701000050630+50000508==============*
1997-07-01 02:00:01 CEST 22718210260319970701000050630+50000500 Time from *
1997-07-01 02:00:02 CEST 22718210260319970701000050630+50000501 TUG *
1997-07-01 02:00:03 CEST 22718210260319970701000050630+50000502 *
1997-07-01 02:00:04 CEST 22718210260319970701000050630+50000503 *

Here is the NMEA output of a Motorola Oncore (8-channel GPS) with the leap second on the bold line (fyi, the sentences are the ones enabled after exiting the ShowTime program and there was a short pause after each ZDA sentence so I believe it should be associated with the preceding GGA/GSA/GSV sentences):

$GPGGA,,4746.442,N,12204.811,W,0,04,,123.3,M,18.2,M,,*7D
$GPGSA,A,1,21,,,01,31,,03,,,,,,,,*1D
$GPGSV,2,1,08,01,25,186,13,03,52,262,15,09,13,087,,17,36,108,*71
$GPGSV,2,2,08,21,71,264,23,23,65,055,,26,12,039,,31,31,307,11*7E
$GPZDA,235959.00,30,06,1997,00,00*64
$GPGGA,,4746.442,N,12204.811,W,0,04,,123.3,M,18.2,M,,*7D
$GPGSA,A,1,21,,,01,31,,03,,,,,,,,*1D
$GPGSV,2,1,08,01,25,186,13,03,52,262,15,09,13,087,,17,36,108,*71
$GPGSV,2,2,08,21,71,264,23,23,65,055,,26,12,039,,31,31,307,10*7F
$GPZDA,235960.00,30,06,1997,00,00*6E
$GPGGA,,4746.442,N,12204.811,W,0,04,,123.3,M,18.2,M,,*7D
$GPGSA,A,1,21,,,01,31,,03,,,,,,,,*1D
$GPGSV,2,1,08,01,25,186,13,03,52,262,15,09,13,087,,17,36,108,*71
$GPGSV,2,2,08,21,71,264,23,23,65,055,,26,12,039,,31,31,307,10*7F
$GPZDA,000000.00,01,07,1997,00,00*66

And here is the NMEA from my Magellan ProMARK X-CM (no ZDA sentence and weak antenna so we can't trust the results but I've boldfaced what I think is the attempted insertion of leap second slightly early - note that apparent missing seconds like :59 and :02 are common and I think related to something like baud rate rather than leap second):

$GPGGA,235955.68,4746.390,N,12204.795,W,1,04,5.7,109.7,M,-18.2,M,,
$GPGLL,4746.390,N,12204.795,W,235955.68,A
$GPVTG,199.0,T,178.6,M,0.3,N,0.6,K
$GPGGA,235956.68,4746.390,N,12204.796,W,1,04,5.7,109.9,M,-18.2,M,,
$GPGLL,4746.390,N,12204.796,W,235956.68,A
$GPVTG,201.3,T,180.9,M,0.4,N,0.7,K
$GPGGA,235957.68,4746.390,N,12204.796,W,1,04,5.7,110.5,M,-18.2,M,,
$GPGLL,4746.390,N,12204.796,W,235957.68,A
$GPVTG,204.0,T,183.6,M,0.4,N,0.8,K
$GPGGA,235957.68,4746.390,N,12204.796,W,1,04,5.7,110.9,M,-18.2,M,,
$GPGLL,4746.390,N,12204.796,W,235957.68,A
$GPVTG,207.6,T,187.3,M,0.5,N,1.0,K
$GPGGA,235958.68,4746.390,N,12204.796,W,1,04,5.7,111.2,M,-18.2,M,,
$GPGLL,4746.390,N,12204.796,W,235958.68,A
$GPVTG,212.2,T,191.9,M,0.6,N,1.1,K
$GPGGA,000000.68,4746.391,N,12204.796,W,1,04,5.7,111.7,M,-18.2,M,,
$GPGLL,4746.391,N,12204.796,W,000000.68,A
$GPVTG,226.2,T,205.9,M,0.8,N,1.4,K
$GPGGA,000001.68,4746.391,N,12204.796,W,1,04,5.7,112.2,M,-18.2,M,,
$GPGLL,4746.391,N,12204.796,W,000001.68,A
$GPVTG,237.4,T,217.0,M,0.9,N,1.6,K
$GPGGA,000003.68,4746.391,N,12204.796,W,1,04,5.7,112.4,M,-18.2,M,,
$GPGLL,4746.391,N,12204.796,W,000003.68,A

And here is the continuous output from an Arbiter 1088A (the ? is a status character):

97 181 23:59:58.000
97 181 23:59:59.000
97 181 23:59:60.000
? 97 182 00:00:00.000
97 182 00:00:01.000

And from a TrueTime NTS-100 (control character edited out - not sure why I was getting "." as the quality character but I don't think it is related to the leap second):

181:23:59:58.
181:23:59:59.
181:23:59:60.
182:00:00:00.

I think the i/o registers from my TrueTime IRIG card (using NTS-100 as source so we don't know whether the error is with the source or the card or both) went something like the following, with the bold lines appearing to be partial rather than complete seconds:

23:59:59
0:00:00
0:00:01
0:00:02
0:00:03
0:00:04 flagged time code invalid and phase unlocked
0:00:05 flagged time code invalid and phase unlocked
0:00:06 flagged phase unlocked
0:00:07 flagged phase unlocked
0:00:08 flagged phase unlocked
0:00:09 flagged phase unlocked
0:00:08 flagged phase unlocked
0:00:09 flagged phase unlocked
0:00:10 flagged phase unlocked

I didn't notice the i/o registers from my bc627AT change as expected, unless they duplicated the 23:59:59 second (my log didn't let me see the previous seconds).

I experimented with revisions to TimeServ and have included excerpts below. The first section of output is via the HP 58503A. I set the time at 4:57:30.044pm PDT (23:57:30.045Z) and had warning of leap second pending. Normally there would have been a delay of a little over 45 minutes before setting the time again, but the new code optimized it so that we'd set the time again just after 5:00:00pm where we expected the leap second. At that time the PC's clock was one second "ahead" and we set it back to the proper 5:00:01.044pm, then logged that we encountered a leap second. The second section (from another PC) is similar, but instead of the HP it used NTP (including a randomizer of about 32 seconds that turned out to be about 20 seconds this time). Although not done here, a further optimization might have been to insert the leap second automatically very close to 5:00:00pm, and just set the time after the normal period (where everything would hopefully agree).

Time was -57:30.076
Time is -57:30.044
Error 32ms
Note: leap second coming
within 24 hours
and we'd sleep through it, so shortening sleep from 2740s to 151s
Time was -00:02.026
Time is -00:01.044
40000005 reported to Application Log in Event Viewer
Error actually -18ms

Time was -13:16.716
Time is -13:16.704
Error 12ms
Note: leap second coming
within 24 hours
and we'd sleep through it, so shortening sleep from 43258s to 2824s
Time was -00:21.085
Time is -00:20.109
40000005 reported to Application Log in Event Viewer
Error actually -24ms

The most recent leap second was announced as follows:

So I got another chance to test things.  I tried to call USNO but made a mistake in modem/terminal configuration so missed it.

A TimeServ example from Ultralink's WWVB is:
Time was -58:18.791
Time is -58:18.789
Error 2ms
Note: leap second coming
within 24 hours
and we'd sleep through it, so shortening sleep from 5052s to 3884s
8000000e reported to Application Log in Event Viewer
(Doug manually aborted the program at that point - if left running it would have presumably detected the leap second about 1.4 hours later.)

Although my "shortened sleep" was the proper amount to get first peek at an updated time, unfortunately the 0e event means that I read an improper time from the device so didn't use it (I didn't have enough debugging output displayed to see further details).  Of course I investigated whether that was a bug in my new Type=Ultralink code but first indication was that it could be due to mistaken .E firmware RTC rollover to day 0 instead of 1 (not unexpected broadcast of day "0" from WWVB)

I verified that NTP via NTS-100 still behaved as expected (described earlier above):
Time was -23:22.188
Time is -23:22.171
Error 17ms
Note: leap second coming
within 24 hours
and we'd sleep through it, so shortening sleep from 43240s to 2201s
Time was -00:03.514
Time is -00:02.503
Error 1011ms
40000005 reported to Application Log in Event Viewer
Oops, Error actually 11ms
Skew 431.9682ms/d

NMEA output from my Javad Legacy GPS receiver was as expected except an extraneous line "LM: Start" (I've notified JPS and asked them why GN rather than GP, and will also ask whether the + is correct since I don't see it in the spec example):
$GNZDA,235957.00,31,12,1998,+00,00*54
$GNZDA,235958.00,31,12,1998,+00,00*5B
LM: Start
$GNZDA,235959.00,31,12,1998,+00,00*5A
$GNZDA,235960.00,31,12,1998,+00,00*50
$GNZDA,000000.00,01,01,1999,+00,00*5B
$GNZDA,000001.00,01,01,1999,+00,00*5A

Continuous output from a Spectracom Netclock/GPS (format 4) was as expected except old 1.04 firmware did not include warning (I've since updated to 2.00):
0004 51178 235958.0000
0004 51178 235959.0000
0004 51178 235960.0000
0004 51179 000000.0000
0004 51179 000001.0000

Also I watched that 1PPS output from my HP 58503A didn't have any obvious glitch compared to my Cs, and no unexpected alarm light came on it or Loran-C.

Back to TimeServ