The “Y2K” of GPS.
GPS also has a field for storing the number of leap seconds (so receivers can compute UTC from atomic time). This is currently at 37, and has been incrementing pretty steadily since the system was created.
There’s a plot here: https://www.e-education.psu.edu/geog862/node/1875
If you were making a GPS receiver, and wanted to give it better odds of working from a cold start with no idea of the current date, you could use the leap second number to make a guess at how many times the week counter has overflowed.
This page has some more details about the GPS signal, and talks briefly about using leap seconds deal with the rollover: https://web.archive.org/web/20180922192530/https://www.colorado.edu/geography/gcraft/notes/gps/gpseow.htm
It’s unclear to me how exactly the week value affects time and date calculations.
Of the “normal” ways to represent time using a single number, the usual are to use “seconds since an epoch” (Unix time) or “fractional days since an epoch” (Julian date).
I’m imagining that the GPS system would represent the date as “Weekday X of Week Y (in “week epoch” Z)” which raises all sorts of weird casting issues when you want to translate it into a human-readable date. I mean, conceptually it’s the same as the methods outlined above, it just feels a sui generis.
I found this overview which gives a good description. Apparently, it’s week number plus seconds since week start, and many devices used to just hard code the current epoch.
Perfect, just the info I was looking for.
Edit interestingly, the issue doesn’t seem to be with GPS per se, instead it’s part of the protocol (NMEA) that the satellites use to talk to receivers.
Edit edit I am an idiot, I will read the entire document before saying anything.
Is there a list of rollover dates anywhere? Prior to reading this, I had known only of the 32-bit UNIX timestamp rollover in 2036 or thereabouts.
This is the best I managed to find.
Thank you. I added this bug to that list.
I bet literally every firmware out there using 8 to 32-bit counters is prone to such bugs (I’ve heard people using Z80-based appliances running since late 1980’s, they just ignore the timestamp field which didn’t foresee leap years and changes in daylight savings).
That only happens because of the usual obsession to ship a product ASAP because “in a few years it will be either broken or out of warranty”.
Well, Y2K was one I guess.
Interesting that this same thing happened 20 years ago, in 1999, when consumer GPS systems, while not as popular and prevalent as they are today, did exist. I don’t remember hearing anything about a GPS rollover at the time, even though the vaguely-similar Y2K bug was all over the news and pop culture.
Back in 1999 consumer GPS units were pretty rare eg: Garmin 12 and similar. Selective Availability severely limited their accuracy so they weren’t much use in town but they were still useful for eg: offroad motorcycling in remoter parts & doing daft things like finding confluence points: http://confluence.org/photo.php?visitid=4068&pic=3
But GPSes were pretty rare and not really thought of as a “computer thing” … I was involved in Y2K planning & testing but don’t remember this being discussed at the time.
ESR has some interesting posts on GPS rollovers:
Interesting that they started providing L2C (the newer protocol with 13 bit week counter) in December 2005 but only reached initial operating capability (ie enough satellites have this) in late 2016:
So probably not a lot of devices using that one yet.
(As other comments and the article point out, you don’t need the new protocol to be rollover safe - but the firmware needs to be aware of the rollover.)