> As seen at > http://lists.ntp.org/pipermail/hackers/2015-May/006866.html > and also as experienced at Keck Observatory last night, some models > of GPS time servers just did their firmware's W1K rollover, so those > are saying the date is 1995-09-17. > > But the leap second is, inappropriately, getting the blame!
Steve, No need to take it personally. At some level it doesn't matter if it's leap seconds, or the GPS spec, or one GPS manufacturer, or one particular GPS receiver model, or one OS, or one line of code that doesn't handle rollover correctly. To the person who wants and expects time to work right, it's all the same. And any of us who work with precise time are part of the problem and share the blame. What you can do is represent the astronomical community and do what you can in your professional career to promote clean, robust, and redundant timekeeping. That can either be passive education or active steering the future away from sextants, s/w radio, and other outdated methods of astronomical timekeeping. That doesn't make problems vanish right away, it helps reduce risk in the future. As you know the GPS folks enlarged the 10-bit week number in the next signal spec so receiver manufacturers have less rope to hang themselves. One step at a time, but at least it's a step. The shame in today's example rests on makers of TymServe 2100, who either didn't test their firmware, or who knowingly allowed a product to have this bug. And worse yet, are now refusing to support it, because it's "out of warranty". Hopefully a two-line fix to NTP can be used to get around the bug. OTOH, I can't believe the Keck guys are reliant on a single GPS receiver for their time? May I bring them another clock or two for them to use? /tvb _______________________________________________ LEAPSECS mailing list [email protected] https://pairlist6.pair.net/mailman/listinfo/leapsecs
