GPS Week Rollover

In brief: GPS satellites broadcast the date as a week number. The original signal has room for only 1,024 weeks (about 19.6 years), so the count goes back to zero. That happened in August 1999 and April 2019, and the next time is 20–21 November 2038, ten months after the Unix 2038 overflow. A GPS receiver that guesses wrong about which 1,024-week cycle it is in will show a date about 19.6 years in the past. This has grounded weather balloons, delayed airline flights and taken down a city network. Newer GPS signals use a 13-bit week number that lasts until 2137.

Overview

GPS time started at midnight between 5 and 6 January 1980 (1980-01-06T00:00 GPS time) ^[1][2]. The legacy navigation message (LNAV) on the civil C/A code broadcasts the week number in a 10-bit field, holding 0–1,023. After week 1,023 it wraps to 0. The full week count is unambiguous only if the receiver already knows which 1,024-week "era" it is in, which usually comes from a firmware constant or pivot date ^[2].

The UTC instant differs from GPS midnight because GPS time does not include leap seconds. In April 2019 the offset was 18 seconds, so the GPS rollover at 00:00:00 happened at 23:59:42 UTC ^[2]. The exact UTC time of the 2038 rollover depends on any leap seconds added before then. This is why sources give the date as "20/21 November 2038".

The third rollover is a separate bug from the Year 2038 problem. It comes about ten months after the Unix overflow. A device that uses both GPS and 32-bit time_t, such as a cheap GPS-disciplined NTP server on 32-bit Linux, can hit both in 2038 ^[4].

Technical details

The arithmetic

1024 weeks × 7 days × 86 400 s = 619 315 200 s ≈ 19.62 years
GPS epoch 1980-01-06 + 1024 weeks = 1999-08-22
              + 2048 weeks = 2019-04-07
              + 3072 weeks = 2038-11-21   (GPS time)
              + 8192 weeks = 2137-01-06   (13-bit CNAV)

(Computed from the 1980-01-06 epoch. The 2019 and 2038 dates match GPS.gov ^[1].)

13-bit CNAV week number

The modernised civil navigation message (CNAV, carried on L2C and L5) uses a 13-bit week number, 0–8,191, which gives a cycle of about 157 years. The first CNAV rollover is in 2137 ^[1][3]. A 2019 Interface Control Working Group proposal to revise IS-GPS-200 states that "one 13-bit CNAV epoch is equal to 8192 weeks" ^[5]. The 13-bit field only helps receivers that actually decode CNAV. Devices that use only the C/A code and LNAV will still roll over in 2038 ^[1].

How receivers guess the era

Most receivers add a fixed number of 1,024-week cycles based on a pivot date, usually close to the firmware build date. If the decoded week falls before the pivot, they add 1,024 weeks. This postpones the failure to 1,024 weeks after the pivot, not to a fixed calendar date. The NTPsec documentation notes that "most vendors don't document their base or pivot dates", recommends assuming that a cheap or unknown GPS unit may roll over on first use, and suggests replacing GPS reference clocks about every nine years (half a GPS era) ^[2]. As a result, failures happen on different dates for different devices. GPS.gov notes that some devices failed months before or after the 2019 rollover itself ^[1]. Meinberg makes the same point. With a firmware threshold, the error "can occur at an arbitrary weekend when the number reaches the threshold determined by the firmware developers", which "doesn't occur at the same time as the scheduled week number rollover" ^[10]. An incident record should therefore give the actual failure date, receiver model and firmware, and should not simply be filed under a scheduled rollover date.

A different approach avoids the fixed pivot. Meinberg says its own receiver firmware "uses a 16 bit week number internally, and the week number is simply incremented". After power-up, the initial extended week number is computed from the date kept in the battery-backed real-time clock. Only a failed backup battery can then yield the wrong era, and setting the correct date fixes it ^[10]. This is a vendor statement about its own products. Meinberg discusses modules with third-party GNSS cores separately ^[10].

Related: two-digit years in NMEA

Many receivers report only a two-digit year in NMEA 0183 sentences. ntpd's NMEA driver infers a four-digit year, which NTPsec says works until 2399 ^[2].

Documented failures

The Telstra date of 2006 is about 1,024 weeks before July 2026 (2026-07-08 − 1,024 weeks = 2006-11-22, our arithmetic). That pattern is consistent with a week-rollover era error, but the published review summary describes it only as the GPS card's date being reset to 2006 ^[9].

Affected versions / products

Risk & compliance notes

• Two 2038 deadlines. Inventories should list both the Unix overflow (2038-01-19) and the LNAV rollover (2038-11-20/21).
• Pivot dates are hidden. Ask vendors for the documented pivot and base dates. If they are unavailable, treat the firmware date plus 1,024 weeks as the likely failure date ^[2].
• Timing is critical infrastructure. The Telstra review found unclear ownership of the timing system and prior government warnings that had not been acted on ^[9].

Detection & mitigation

1. Inventory GPS receivers by role (time source vs. position only) and record their firmware date.
2. Use GPS simulators to test receivers through the rollover and past their firmware date + 1,024 weeks. The rollover comes from the satellite data stream, so changing the date in a receiver's user interface is not an equivalent test ^[10].
3. Take care when moving a receiver's date across eras during tests. Stored navigation data then has "a reference time 1024 weeks in the future or past". Meinberg advises setting the receiver to cold boot mode after the correct date is set. Recollecting the data takes about 12 minutes ^[10].
4. Prefer receivers that decode CNAV (L2C/L5) or multiple GNSS constellations, and cross-check against independent time sources.
5. In NTPsec, the time1 offset suffixes "g" and "G" add 1,024 or 8,192 weeks after a rollover has been detected ^[2].
6. Keep GPSD/NTPD current (≥ 3.23.1) ^[1].

See also Testing-and-Detection.

See also

• Related-Date-Bugs
• NTP-Era-2036
• Year-2038-Problem
• Devices-Networking-and-IoT
• Known-2038-Incidents

References

1. GPS Week Number Rollover — GPS.gov (archive). The 10-bit field, rollover dates, "November 20, 2038" for LNAV-only devices, CNAV to 2137, and the 2021 GPSD note.
2. Rollover issues — NTPsec documentation. GPS epoch, 2019 UTC time 23:59:42, pivot dates, vendor practices and NMEA years.
3. GPS week number rollover — Wikipedia. 1999 disruption, CNAV 2137, and a list of 2019 failures (secondary).
4. Time synchronization and rollovers — Meinberg KB (updated 2025-03-20). Interplay of GPS, NTP and Y2038 in time servers.
5. Clarifying Continuous GPS Time — GPS ICWG, Sep 2019. 13-bit CNAV epoch of 8,192 weeks (seen in search).
6. GPS Rollover Hamstrings New York City Wireless Network and a Handful of Other Systems — Dee Ann Divis, Inside GNSS, 11 Apr 2019.
7. GPS Week Rollover grounds Aussie weather balloons, Boeing planes — Tracy Cozzens, GPS World, 9 Apr 2019.
8. Time to party like it's 2002: Acura and Honda car clocks knocked back 20 years by bug — Thomas Claburn, The Register, 6 Jan 2022.
9. Telstra outage caused by failure to prioritise well-known network vulnerabilities — ABC News, 2 Sep 2026.
10. GPS Week Number Rollover — Martin Burnicki, Meinberg KB, 2024-07-10. Fixed-threshold failures on arbitrary weekends, Meinberg's 16-bit internal week number and RTC seeding, simulator testing and cold boot (vendor statement).
11. Update your iPhone or iPad software if you're experiencing issues with location, date, and time — Apple Support (archived article). Affected models, iOS 10.3.4 / 9.3.6, impact just before 00:00 UTC on 2019-11-03, computer restore for iPhone 5.
12. Omzet TomTom groeit 12 procent in Q2 — Telecompaper, 2019 and I vecchi navigatori GPS potrebbero essere colpiti da una sorta di "Millennium bug" — SmartWorld, 2019. Secondary reports of TomTom's Q2 2019 sales effect and pre-rollover statement (seen in search results).