April 6, 2019 is Y2K (or 8/21/99) all over again, for old GPS devices

April 5, 2019 12:04 PM

If you use your smartphone for GPS navigation, or pretty much any other GPS receiver released in the past decade you can probably ignore this next link -- but if you have an older GPS receiver, it may malfunction on or around April 6, 2019. (Liliputing) GPS “rollover” event on April 6 could have some side-effects -- GPS’s UTC clock, used for more than navigation, is about to reset. There might be some surprises. (Ars Technica) It's no Year 2000 Problem (Wikipedia) ... well, it is, in a way. It's another time formatting and storage bug (Wikipedia), and this particular GPS hiccup already happened, at 23:59:47 on Saturday 21 August 1999 (more details from 1998, PDF).

"Why haven't they learned?" you might ask. Well, time bugs have existed since time was used in computers ....

Though there weren't computers before AD 0, certain classes of calculations in disciplines such as astronomy and physics have a Year Zero Problem (Wikipedia), and may count back from zero with negative years to compensate.

The Wikipedia article on time formatting and storage bugs notes that 1970 was the first time that some code rolled over because some time-specific code was written with a single digit for the year in the 1960s, but there's no citation, so we'll leave it at that, except to note that setting your iOS device clock to January 1, 1970 would brick the device (OSX Daily), or at least, it would, assuming Apple fixed this bug (Mac Rumors).

9 January 1986 was another trigger-date (The Risks Digest), when "Users of the TOPS-10 (Wikipedia) operating system should beware of software failures beginning on that date." 18 September 1989 and 2 November 1997 were similarly problems for some mainframe programs, and the Domain/OS (Wikipedia) clock, respectively.

There was plenty to do to prepare in 1999, as detailed in Arnold's Year 2000 Checklist, and specifically 9/9/99 was another possible problem date (Information Week, archived), as discussed on Slashdot. The Millennium Bug wasn't much of an issue because lots of people worked quite hard in advance, as recounted 10 years later in an InfoWorld article, when "Y2.01k" glitches hit Bank of Queensland (BOQ) EFTPOS terminals, which malfunctioned as clocks ticked over to January 1, 2016 (CRN.com.au), and a Windows Mobile bug dated messages from 2016 (Wired).

Taiwan’s Y1C problem (Pinyin.info) hit on 1 January 2011.

Deep Impact's fault-protection software (ironically enough) had its own Y2k bug (National Geographic), where it would have misread any date after August 11, 2013, triggering an endless series of computer reboots aboard the spacecraft.

In addition to the upcoming GPS clock reset, programmers are preparing for the new Japanese calendar era (Community.Dynamics.com) in the near future.

An anecdote from Stack Overflow: "I know of COBOL systems coded in the 1950s with a date format good until 2027 -- must have seemed forever at the time; and I designed systems in the 1970s that are good until 2079."

There are some more legacy system concerns in the coming decades, with Network Time Protocols rolling over on February 7, 2036 (Wikipedia), and then many digital systems that record the time as the number of seconds passed since 1 January 1970 and storing it as a signed 32-bit binary integer cannot encode times after 03:14:07 UTC on 19 January 2038, AKA the Year 2038 problem (Wikipedia). See also: A look at the Year 2036/2038 problems and time proofness in various systems (Lieberbiber).

MeFite mdeatherage noted

The clock chip in most Macintosh computers just records a number of seconds. By definition, classic Mac OS treated this as the number of seconds since January 1, 1904, at midnight (local time). When the 32-bit clock register fills up at 0xFFFFFFFF, it will be February 6, 2040, at 6:28 AM local time.

The replacement Apple File System resolves this issue.

The TI-83/84 series calculators days-between-dates function has always had a very limited range: years 1950 to 2049. TI is apparently not worried about this, I suppose because 30-year mortgages begun this year would terminate in 2047, but in 2020 this gets to be an issue. (HP Museum forum post)

There are some more roll-over or error-producing dates in the farther future, but hey, that's so far away, right?

posted by filthy light thief (26 comments total)

Where it gets really interesting is when you add time zones to the mix. So its already 6th April in Australia and New Zealand, all through South East Asia and possibly now South Asia, but still under two hours to midnight of the 5th in Eastern European Time but only noonish on the 5th of April in San Francisco.
posted by infini at 12:20 PM on April 5, 2019 [3 favorites]

My dashboard GPS needs its map info updated anyway, so this is a good reminder to get off my ass and do it.
posted by tobascodagama at 12:29 PM on April 5, 2019

There are 20 automated marine weather stations around the U.S. that are going to stop working indefinitely due to this issue. That will significantly impact the ability of forecasters to provide accurate marine forecasts.
posted by jkent at 1:27 PM on April 5, 2019 [9 favorites]

I just know that DeLorme is going to ignore this, but at the same time I bet my old PN-20 and PN-60 will work just fine anyway
posted by wenestvedt at 1:39 PM on April 5, 2019 [1 favorite]

It's already April 6 in many parts of the world. Anything happening?
posted by dances_with_sneetches at 2:07 PM on April 5, 2019

GPS Time is UTC (ignoring leap seconds), so the fireworks if any will be in another 82 minutes.
posted by phliar at 3:38 PM on April 5, 2019 [1 favorite]

My dads GPS (a handheld/pocket Garmin one) started telling us it was 1999 about a week ago, so now I'm wondering if that's due to this, or a coincidental break down.
posted by dng at 3:43 PM on April 5, 2019

I was just reading an article about how the change of the new Japanese era is causing Japanese IT workers headaches.
Also, in a lot of old but important systems, they punted the handling of the change of the last era (Heisei) by sticking with the 昭和 Showa era year counting underneath the 平成 Heisei year representation. But Showa Year 1 was 1926, which means it's going to be Showa Year 100 in 2026, and those systems use TWO DIGITS (like any sane person back then when the systems were built) to hold the year value. So apparently in 6-7 years or so it's going to be Y2K all over again in Japan.
posted by em at 4:14 PM on April 5, 2019 [1 favorite]

My dads GPS (a handheld/pocket Garmin one) started telling us it was 1999 about a week ago, so now I'm wondering if that's due to this, or a coincidental break down.

Maybe some unrelated breakdown caused it to think it was a week in the future.

If you can sync it with a computer or something, you might be able to apply a firmware update.

(FWIW Garmin has already declared that all of their aviation units, regardless of age, do not exhibit the 4/6/2019 rollover issue.)
posted by tobascodagama at 4:45 PM on April 5, 2019 [1 favorite]

Well it's April 6 in UTC now and nothing seems to have fallen out of the sky. The OA Season 2 is still inexplicably available on Netflix. So I guess all is well?
posted by Nelson at 5:29 PM on April 5, 2019 [2 favorites]

I've two old garmin GPS units, a hand held and a car dash unit somewheres. I bet the hand held if the battery is still okay have this issue.
posted by 922257033c4a0f3cecdbd819a46d626999d1af4a at 6:09 PM on April 5, 2019

Where it gets really interesting is when you add time zones to the mix.

Ain't it always.

You know at some point I have to wonder if it wouldn't be better just to ditch zones altogether. Yeah, so what if it's the middle of the night when the clock reads 09:00? And? What's the harm?

The savings in software development time alone would be... well I don't really know for sure, but I'm betting it's very, very, very much non-zero.

(Of course I am biased as hell, since I'd fathom a guess that my teams and I have spent somewhere on the order of several person-weeks on timezone-related problems. But I doubt we've all been outliers...)
posted by -1 at 8:20 PM on April 5, 2019 [3 favorites]

We just moved over to Summer Time last weekend, and if all goes well, this is our second to last year of time changes. An overwhelming vote to throw out Daylight Savings Time.
posted by infini at 11:26 PM on April 5, 2019 [2 favorites]

Macs may have a tough time in 2040, but the Apple Lisa ran out of years in 1996. The clock chip used only four bits for the year, counting up from 1980. Happily, this was more than enough.
posted by tss at 2:52 AM on April 6, 2019 [1 favorite]

My dads GPS (a handheld/pocket Garmin one) started telling us it was 1999 about a week ago, so now I'm wondering if that's due to this, or a coincidental break down.

Some of us will do whatever it takes to escape the 21st C....
posted by GenjiandProust at 4:14 AM on April 6, 2019 [1 favorite]

Huh, I bet this breaks the old Garmin eMap I lost that I still miss having. That thing was a little tank of a device.
posted by loquacious at 6:09 AM on April 6, 2019 [1 favorite]

"No, Marty. Both you and Jennifer turn out fine. It's your code, Marty! Something's got to be done about your code!"
posted by RobotVoodooPower at 8:17 AM on April 6, 2019 [3 favorites]

You know at some point I have to wonder if it wouldn't be better just to ditch zones altogether.

No no no, you're going about this all wrong... you've got to steer into the skid. We don't need less precision, we need more! Infinitely more! Timezones are created by arbitrary longitudinal demarcations causing large, discrete jumps in time at unexpected geographical intervals. That's silly; why perform discrete math on what is clearly a continuous problem? With ubiquitous GPS and remote synchronized timekeeping, you'll always have an exact longitude and an exact GMT. That means we don't have to worry about hour boundaries; we can calculate your local time to the millisecond! It's 5:00 in New York City? Then it's 4:54:30 in Boston, and 5:01:13 in Albany

You can license my timekeeping library for a very reasonable fee, but you'll want to budget for the time it takes to download 4.8 GB of source code from the GitHub repo.
posted by Mayor West at 8:38 AM on April 6, 2019 [5 favorites]

We just moved over to Summer Time last weekend

I was on the train east to St Petersburg a few years ago, and I was reading the on train magazine and wondering how on earth the journey got an hour longer at the end of October without anyone mentioning major engineering works.

It took a while before I realised that Russia had already abandoned seasonal clock changes.

And of course until trains existed, everyone did use local time, set by a central clock in a visible place.
posted by ambrosen at 8:52 AM on April 6, 2019 [2 favorites]

And doesn't the former U.S.S.R. (and perhaps only Russia proper) cover like eleven time zones??
posted by wenestvedt at 12:13 PM on April 6, 2019 [1 favorite]

Well, it does, but it's ridiculous. It's not even funny.
posted by tss at 12:45 PM on April 6, 2019 [7 favorites]

But the GPS version of the clock tracks the date by counting the number of weeks since the beginning of the current GPS “epoch”—August 21, 1999.

Most other systems use seconds or milliseconds since Jan 1, 1970. Why did the GPS designers go with a different epoch and a different increment?
posted by Triplanetary at 2:00 PM on April 6, 2019

GPS is solving some very different problems to most time storage media, Triplanetary. From Wikipedia:

GPS time is expressed with a resolution of 1.5 seconds as a week number and a time of week count (TOW). Its zero point (week 0, TOW 0) is defined to be 1980-01-06T00:00Z. The TOW count is a value ranging from 0 to 403,199 whose meaning is the number of 1.5 second periods elapsed since the beginning of the GPS week. Expressing TOW count thus requires 19 bits (219 = 524,288). GPS time is a continuous time scale in that it does not include leap seconds; therefore the start/end of GPS weeks may differ from that of the corresponding UTC day by an integer number of seconds.

There's, err, far more data than that on the linked page if you can make sense of it. But it's doing such weird stuff with time that you can understand why an incrementing integer count of seconds might not make that much sense.
posted by ambrosen at 2:40 PM on April 6, 2019 [2 favorites]

This GPS rollover event went a lot more smoothly than the previous one did, in my opinion. This time around, I have a couple of old (mid-2000's) car nav units that now have broken clocks, but they still navigate fine (aside from out of date map data that can be fixed with OpenStreetMap)

Last time around, I had a nifty little hand-held GPS for hiking, and... it used the GPS time data to compute what the constellation was supposed to look like; which never matched again, and it could never sync up for position before it timed out and turned itself off.

I'm curious how many of the remaining functional devices actually use a separate value for which epoch, and how many are sneakily using a fixed offset internally and will mysteriously expire some 20 years from their initial design moment. I don't trust Garmin or DeLorme to do it right for consumer-level equipment, even if my silly sports watch is still currently functional.
posted by Xyanthilous P. Harrierstick at 8:41 AM on April 7, 2019 [1 favorite]

Mercifully, the GPS ‘millennium bug’ was a massive letdown (Matthew Hughes for The Next Web, April 8)

Unfortunately, some Boeing 787 aircraft fell victim to the rollover, with crucial avionics systems showing the wrong date. This has resulted in several Chinese airlines grounding planes while they wait for a software update.
...
That aside, the GPS Rollover really wasn’t as bad as many people feared (or, perhaps more accurately in the case of the Daily Mail, fearmongered). The good news is that the powers that be are working to address this issue by increasing the size of the GPS WN from 10 bits to 13 bits, allowing it to store 8,192 weeks, or 157 years. This means that the next time we face this problem again will be sometime in 2137.

That's a rather large "aside."
posted by filthy light thief at 8:58 AM on April 8, 2019 [1 favorite]

Ars Technica has a bit more details on those flight impacts: Somebody forgot to upgrade: Flights delayed, cancelled by GPS rollover -- Date bug on unpatched Honeywell gear likely cause of 777, 787 flight cancellations. (Sean Gallagher for Ars Technica, April 9, 2019)

The world did not come to an end this past weekend when the 10-bit calendar-week counter in the Global Positioning System’s precision timing system “rolled over” back to 0000000—an event that caused older, unpatched GPS systems to suddenly act like they had jumped nearly 20 years back in time. But the long-anticipated reset of the calendar count did apparently lead to cancellations of some airline flights overseas, as technicians failed to catch warnings and update firmware.

posted by filthy light thief at 1:47 PM on April 10, 2019 [1 favorite]