GPS week-number rollover — 20 November 2038

Legacy GPS navigation messages count weeks in 10 bits. The counter rolls every 1,024 weeks, about 19.6 years. The next roll of that field is 20 November 2038. It is not the Unix overflow on 19 January.

Field	GPS week number in the legacy LNAV message, 10 bits
Epoch of the count	6 January 1980
Period	1,024 weeks
Previous rolls	21–22 August 1999; 6 April 2019
Next legacy roll	20 November 2038
Newer civil messages	CNAV uses 13 bits; that field lasts until 2137

What broke in 2019

On 6 April 2019 some older receivers reset their date to August 1999 or to another week inside the previous era. Position could still be fine. The date stamp was not. NOAA and the US Coast Guard warned about this before the roll: the failure mode is a wrong date, not a loss of the constellation.

TechCrunch covered that roll as a device-date bug. The write-up is on the Media page. The same class of receiver, if never patched, meets the same field again on 20 November 2038.

Why this is not Y2038

Unix time counts seconds from 1970 in a signed 32-bit integer. GPS week counts weeks from 1980 in 10 bits. A survey receiver can fail the week number and still have a correct 64-bit POSIX clock. A Linux box can pass 2038 and still mis-set its clock if it trusts an old GPS module for time.

The practical check is the firmware date and whether the vendor’s 2019 advisory was applied. “GNSS inside” on a datasheet is not a 2038 statement.

What to record

Receiver or module model, firmware build, and whether it claims a 13-bit week or an explicit post-2038 date test.
Whether the host sets its system clock from the GPS time-of-week plus week number. That path can import a bad date into an otherwise safe OS.
Do not set a production clock to November 2038 to “see what happens.” Use a spare, as on the testing page.

Primary public note: GPS.gov civil-signal statements on the week-number rollover. Related: Unix Y2038, NTP 2036.