> > Yeah, my 58503B SmartClock just picked it up too. > > But as I suspected, based on what was reported in > > 1998, it has the date wrong: > > > > scpi > ptime:leap? > > 1 > > scpi > ptime:leap:stat? > > 1 > > scpi > ptime:leap:acc? > > +13 > > scpi > ptime:leap:date? > > +2005,+9,+30 > > That looks similar to the alleged 8 bit week counter overflow Tom > reported for the HP 59551A > (http://www.leapsecond.com/notes/leapsec256.htm). Maybe the 58503B > has a week counter that started at 0 in 2000 ??
Nope, the 2005-09-30 leap second isn't the 256 week bug. What I recall is that it shows up only in HP SmartClock receivers only when the leap second is announced more than 3 months ahead of time. Can someone else confirm this? It was reported in 1998 too when IERS also gave more notice than usual. Doug, you remember this happening in 1998, right? I think it's a simple HP firmware bug where they sort of took the leap second guidelines too literally: "first preference is given to the opportunities at the end of December and June, and second preference to those at the end of March and September." My wild guess is the firmware looks at the leap second subframe fields and then incorrectly schedules the leap second at the end of the nearest quarter year. If there's someone from Agilent or Symmetricom on the list, please consider scanning a page or two of the now ancient SmartClock firmware for the sake of history so we can see what really happened and learn from it. Thanks, /tvb http://www.LeapSecond.com _______________________________________________ time-nuts mailing list time-nuts@febo.com https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts