On 2015-05-05 11:32, Alan Ambrose wrote:
It's not that simple. First, it's not 20 years, but 1024 weeks (19.6 years). And not UTC weeks (which may have leap seconds) but GPS weeks (which do not, and are always 604800 seconds long). etc
Don't think it's _that_ much code though. There's some open source ACM date algorithms, and it would be easy enough to implement a quick and dirty fix, adding a number of days offset, while the rest of the algorithm is tested.
See http://www.leapsecond.com/notes/gpswnro.htm This was first noted in 1996 and has been happening since the first rollover in August 1999 so some affected NTP GPS drivers have been patched to add 1024 weeks while the input is more than 512 weeks in the past.
Will the next time this problem reoccurs be another 20 years?
The next rollover is about April 2019, but this can happen any time an older receiver's internal date representation used for GPS to UTC conversion overflows. Looks like Tymserve 2100 picked about Sep 1995 for its date epoch so it hits now. Newer GPS receivers support the extra 3 bits added to GPS extended week allowing 8192 weeks (157 years) between rollovers - 2137 is the next big rollover problem, but NavStar will likely not be sending the same data on the same frequency then. -- Take care. Thanks, Brian Inglis _______________________________________________ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
