[time-nuts] TymServe 2100 1995 Issue - A Kludgy Fix

Brian Inglis Brian.Inglis at SystematicSw.ab.ca
Wed May 6 16:04:49 UTC 2015


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



More information about the Time-nuts_lists.febo.com mailing list