Can someone sensible with expertise comment on this please?
The rollover problem is a hard one to fix, because there's no reasonable way for a GPS (at least one using LNAV (legacy) signals -- pretty much all of them, though I don't know what modern passenger jets use) to know which GPS "epoch" they're in. If you don't know what epoch you're in, you don't know what the date is.
Some GPSs solve this by recording the week number of their firmware build, and if the signals they get indicate the week number is less than that, they assume they're in the next epoch and update accordingly. Still means you run out of time, but you get a full ~19 years of life first (and then fail at some random GPS week). Some use fuses to record when an epoch has passed. Some use out of band information. Some store the current epoch in flash or battery-backed RAM. Some just never address the problem.
Thing is, though -- the only effect this has, is that it makes the GPS return the wrong date. That's it. The week rollover has no effect on navigation unless there's some significant bugs in the unit, or something external to the GPS relies on the date being output and doesn't deal well with the date suddenly going back in time. That's it.
I'd be kinda shocked if airplanes were just jam-syncing the clocks of their nav computers to the output of a GPS, and then had those nav systems be dependent on that time. But then again, I work in the tech industry, and I've seen the kinda code that goes into most products, so maybe I wouldn't be that shocked.
(I also can't imagine that GPS units used in aircraft aren't directly tested for their behavior during the week rollover. It's a well known and understood problem, and even if some random GPS manufacturer drops the ball, stuff that goes into aircraft has to go through certification for a reason...)
Obligatory not an aircraft software engineer, but I can say with some certainty that this is not the case. Aviation software, despite the recent issues with the 737 MAX, is generally designed and implemented to very high level of redundancy and SPOF-avoidance.
From an airbus manual, to give you some idea:
A300-600s, A310s, A320s, A330s and A340s with GPS PRIMARY
The navigation system of these aircraft consists of 2 FMS, 3 IRS, 2 GPS and radio navaid sensors. The GPS position is primarily used for FM position updates, however if GPS PRIMARY is lost, FM reverts to radio updates or to IRS ONLY navigation when outside radio navaid coverage.
FM(S) = Flight Management (System). IRS = inertial reference system (THREE of them). If GPS is lost or malfunctioning, the FMS falls back to that - which is periodically updated by reference to RNAV ground-based radio beacons. GPS could simply switch off worldwide and aircraft would be fine, just like they were pre-GPS.
There is no conceivable reason the navigation system would especially care about the time being received from its GPS units, let alone perform some critical calculation based upon it. This article is pretty uninformed fear-mongering.
Another option is trying to guess the epoch from the TAI-UTC offset, which, of course, can't be known in advance and to some extent depends on political decisions so that's more of an "interesting" option than a good or practical one.
This is off topic, but since you describe yourself as "gps geek" I thought I ask. Is it possible to gain access to the actual operational code where GPS operators correct for General Relativity? I'm not disputing GR, I just want to find out if this is a myth or true. Thanks.
"The carrier frequencies for the L1 and L2 signals shall be coherently derived from a common frequency source within the SV. The nominal frequency of this source -- as it appears to an observer on the ground -- is 10.23 MHz. The SV carrier frequency and clock rates -- as they would appear to an observer located in the SV -- are offset to compensate for relativistic effects. The clock rates are offset by (delta f)/f = -4.4647E-10, equivalent to a change in the P-code chipping rate of 10.23 MHz offset by (delta)f = -4.5674E-3 Hz. This is equal to 10.2299999954326 MHz. The nominal carrier frequencies (f0) shall be 1575.42 MHz, and 1227.6 MHz for L1 and L2, respectively."
In this context, "SV" is "Space Vehicle", a.k.a. a GPS satellite.
You also have to make a relativistic adjustment in the user segment (aka "your GPS"). You can see an example of doing this correction in open-source software GPS receivers, for example https://github.com/jks-prv/Beagle_SDR_GPS/blob/de895035e93ba... . This adjustment is documented in the above spec, in section 20.3.3.3.3.1 (which you'll see is almost verbatim copied into the the code linked above)
[1] http://www.astronomy.ohio-state.edu/~pogge/Ast162/Unit5/gps....
As an example, clone https://github.com/gnss-sdr/gnss-sdr and search for "relativistic correction"
And I was slightly less asounded when the Nexus S phones spat out broken GPS NMEA sentences on leap years
It's a pretty big oops, but they rebooted the computers, and the planes kept flying. That's the second place where these disaster predictions fall down. These systems are rarely designed with a single point of failure.
As was I, when I learned about taking off from the Dead Sea:
My local airfield is at -19ft and the landed altitude reported by Mode-S varies from -25ft ( GNSS sourced ) to -275ft ( pressure based on 1013hPa ). Hence why asking for the local air pressure QFE is essential.
With most of the things I have used NMEA for (time sync), I did not use the weeks counter. However if there is any software that does use it, it needs to be able to handle the rollover.
I would expect some percent of phones to flip out (try force restarting, or waiting a day and restarting). Which ones are a mystery - the GPS chip in a phone isn't even consistent for a particular model.
I wouldn't expect planes to fall out of the sky. I wouldn't be surprised by flight delays though; just because the safety critical stuff is well tested doesn't mean the rest is.
And the errors aren't going to be confined to April 6th. We're talking about software bugs here, and it's dealing with a number that counts in weeks. So while bugs should center on the 6th, anything within a week of that is pretty plausible too.
(I wrote the GPS tracking algorithm used for navigation in Google Maps. Nothing above is based on Google-specific knowledge. It's still just someone's opinion.)
This is the mechanism that I'd expect someone messed up. I'd expect location errors more than time errors, but because you can get time out of GPS then someone probably has.
[1] https://gssc.esa.int/navipedia/index.php/GPS_and_Galileo_Sat...