> Not what I saw last night. This is what I logged for time codes: > In other words, there were 16 seconds where it was wrong by > a second, and then it realized that something was horribly wrong, > jerked the GPS-UTC offset back by a second, and then raised > the "request for service summary bit" in the status byte register > (That's the "1" that appears as the fourth to last character) > to say that something was FUBAR.
Ah, correct. Although it properly turns off the leap second pending state within one second, looking further down in my log, I also see the time jump. In both your and my case the second labeled 00:00:17 is missing to make up for the 23:59:60 leap second that was added. Cute. 2005-09-30 23:59:58.360 T22005093023595930+0048 2005-09-30 23:59:59.350 T22005093023596030+0040 2005-10-01 00:00:00.340 T22005100100000030+001D 2005-10-01 00:00:01.330 T2200510010000013000023 ... 2005-10-01 00:00:15.280 T2200510010000153000028 2005-10-01 00:00:16.320 T2200510010000163000029 2005-10-01 00:00:17.370 T220051001000018300002B 2005-10-01 00:00:18.360 T220051001000019300002C ... > Only hours later did it realize that another leap second was coming. > > Tim. Interestingly, my Z3801A behaved like yours but my 58503B still reports no leap second pending as of this morning, 15 hours after the event. I put a log on it to see when it finally sets the bit. /tvb _______________________________________________ time-nuts mailing list [email protected] https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
