The NPR new item and audio podcast The Global Positioning System Resets talks about a 19 year cycling of something in the GPS system, but it's not clear what it is.

Every 19 years, the Global Positioning System resets a measure of time built into its program. The latest rollover is Saturday and NPR's Scott Simon asks cybersecurity expert Frank Cilluffo about it.

It's Y2K for GPS. The Global Positioning System was designed with a limit for the number of weeks it could count. Every 19 years, the program reaches that limit and the count resets. That happens tonight. What might happen tonight? Frank Cilluffo is director of the McCrary Institute for Critical Infrastructure Protection and Cyber Systems. He joins us now from the campus of Auburn University. Thanks so much for being with us.

  1. What is it exactly that cycles or "rolls over" every 19 years?
  2. Is it in any way analogous to y2k?
  3. Is there any cybersecurity issue associated with the rollover more subtle than GPS simply not working for some users? For example, is there some hacking potential associated with this moment?
  • 3
    $\begingroup$ @JörgWMittag you are right, it last happened in 1999. However, the prevalence and use of GPS back then was nothing like it is now. $\endgroup$
    – Darren
    Commented Apr 8, 2019 at 16:51
  • 1
    $\begingroup$ @JörgWMittag in fact, that is stated in the article. Also, as per my answer, the date itself may not be a problem, but going forward various receivers may experience problems at unknown and seeminly arbitrary dates. $\endgroup$
    – Darren
    Commented Apr 8, 2019 at 18:23
  • 1
    $\begingroup$ Comments are not for extended discussion; this conversation has been moved to chat. $\endgroup$
    – called2voyage
    Commented Apr 9, 2019 at 16:32
  • 1
    $\begingroup$ Delorme did this. They rolled over sometime in the summer of 2018. As a navigation user, I didn't notice it while using my GPS on a 1 week trip. It mucks up the track data however, and you have to do date math, or use a program like GPSBabel to fix the dates. Garmin has since released firmware version 3.7 which fixes the problem. $\endgroup$ Commented Apr 12, 2019 at 15:36
  • 1
    $\begingroup$ I didn't need to use GPSbabel, as the track data wasn't date crucial. I haven't checked the GPS to see if data that was on it was modified. I don't think it would be. $\endgroup$ Commented Apr 13, 2019 at 22:06

3 Answers 3


The field in the protocol that specifies the week number is a 10-bit value. In most computers, when an (unsigned) integer exceeds its maximum value, it wraps around to zero. This is roughly similar to Y2K, though is more like the upcoming year 2038 problem (but with weeks instead of seconds). This 10-bit value will wrap around, and the GPS system will hold the same time value as it held back in 1999.

Yes, this can cause some security issues. Many people use GPS signals as a way to tell time instead of its traditional use with geolocation. Accurate time is extremely important for security, such as for verifying that a certificate is valid and has not expired. If an operating system exclusively uses GPS to calibrate its internal clock, this rollover could, if handled improperly in firmware, result in certificate validation errors or even the failure to check for security updates. See also How important is local time for security?.

  • 2
    $\begingroup$ To double check, a GPS receiver unit without properly updated software (or firmware) could return a properly formatted yet incorrect value for GPS time, and this problem is independent of the quality of the geolocation data? $\endgroup$
    – uhoh
    Commented Apr 8, 2019 at 5:10
  • 2
    $\begingroup$ @uhoh Correct. If that invalid time is used for purposes that require accurate time for security, this could result in a security issue. $\endgroup$
    – forest
    Commented Apr 8, 2019 at 5:12
  • $\begingroup$ thanks! fyi Does GPS spoofing ever come from space? How are spoofings usually detected? is somewhat security-related. $\endgroup$
    – uhoh
    Commented Apr 8, 2019 at 5:24
  • 1
    $\begingroup$ @uhoh Yes, look at it like the Y2K issue. You see a date that says "20". Two years ago, right? Nope, I'm thinking of my father's birthday. Calendars roll over every 100 years, the GPS satellites roll over every 1024 weeks. $\endgroup$ Commented Aug 2, 2022 at 17:08
  • $\begingroup$ @LorenPechtel okay I see, thanks! $\endgroup$
    – uhoh
    Commented Aug 2, 2022 at 22:05

@forest’s answer is correct. But what makes the rollover slightly more problematic is that many GPS receiver manufacturers have accounted for it by pre-programming an internal “pivot date” in the firmware. That is, if a receiver was manufactured/programmed in, say, 2015, then there is internal logic that says “if the date appears to be prior to 2015, it’s obviously nonsense so add 1024 to the apparent week number”. This means the receiver will roll over, just some time in the future, 1024 weeks after the pivot date.

There’s a good explanation here.

This means that most receivers will roll over at different times making it hard to plan for. The date, unless known by the manufacturer, needs to be tested for (using a GPS simulator you need to go way in the future, then in the past, until you can narrow down the actual date).

Location based receivers (car sat navs for example) should continue to function (although their date may be wrong unless fixed in firmware). However, the prevalence of NTP, PTP and other time-of-day protocols in the finance, power, telecom and many other industries, the source of which is almost always traceable back to GPS, makes this a potential headache.

Side note: Some equipment I’m aware of actually rolled over earlier than the 6th April 2019 date, back in 2018. I’m aware of at least one large-ish telecoms provider experiencing a major outage because they hadn’t accounted for it. Their switches all started receiving a time way in the past which caused them to crash.

Further side note: New GPS satellites (i.e. those launched since around 2014 or so) also broadcast a 13-bit week number value. Any receivers designed to utilise them won't roll over for 8191 weeks, or 157 years.

  • $\begingroup$ Comments are not for extended discussion; this conversation has been moved to chat. $\endgroup$
    – called2voyage
    Commented Apr 9, 2019 at 16:36

Other answers explain the WNRO problem as an overflow/high order truncation/rollover problem.

This is correct.

It is a security issue because services may be impacted. Not all security issues are about data loss. Business continuity is strangely important to people as well.

This type of thing has been going on in the digital world for a while now. Windows 95, 98 and possibly NT 3.51 would crash on millis rollover after 49.7 days.

The real time clock in many early PC motherboards could only cope with an 8 year range, (3 bits) putting a ceiling on the date (1987 for many 8086's).

Enough has been written about Y2K and tm_year from time.h (which did not rollover but got fat). I recall too we had a post Y2K issue with packed decimal (COMP-3) date arithmetic in point of sale systems world wide.

The important thing is that it is foreseeable, so it should be dealt with by software, almanac data, and appliances that depend upon it.


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.