Slashdot Mirror
Your GPS Devices May Stop Working On April 6 If You Don't Or Can't Update Firmware (theregister.co.uk)
Zorro shares a report from The Register: Older satnavs and such devices won't be able to use America's Global Positioning System properly after April 6 unless they've been suitably updated or designed to handle a looming epoch rollover. GPS signals from satellites include a timestamp, needed in part to calculate one's location, that stores the week number using ten binary bits. That means the week number can have 210 or 1,024 integer values, counting from zero to 1,023 in this case. Every 1,024 weeks, or roughly every 20 years, the counter rolls over from 1,023 to zero. The first Saturday in April will mark the end of the 1,024th week, after which the counter will spill over from 1,023 to zero. The last time the week number overflowed like this was in 1999, nearly two decades on from the first epoch in January 1980. You can see where this is going. If devices in use today are not designed or patched to handle this latest rollover, they will revert to an earlier year after that 1,024th week in April, causing attempts to calculate position to potentially fail. System and navigation data could even be corrupted, we're warned. U.S. Homeland Security explained the issue in a write-up this week. GPS.gov also notes that the new CNAV and MNAV message formats will use a 13-bit week number, so this issue shouldn't happen again anytime soon. The site recommend users consult the manufacturer of their equipment to make sure they have the proper updates in place.
Who the fuck designed it, Jony Ive?
Going to ask our hardware supplier about this as soon as I arrive st work.
"It's such a fine line between stupid and clever" -- David St. Hubbins, Spinal Tap
Only after reading the original article I understood the connection between 210 and 1024. Copy-paste is so wonderful.
The last time this happened was while the world was in a complete panic over the Y2K doomsday prophecies, and you're telling me that new GPS units made since then STILL do not have a way of handling this?!
-=This sig has nothing to do with my comment. Move along now=-
There are a limited number of possible fails like this, let's enjoy it.
for every single car manufacturer out there. pretty sure your car's infotainment system will continue to work. But if it doesn't and it is a recent model year, first owner vehicle, you could have a pretty chunky payout up to and including the cost of a new car. pretty sure your car will work on April 7th
They couldn't just go to a 16 bit number they had to save 3 freaking bits ? and for what to have an odd length numeric ?
Another thing to watch out for are delayed failures caused by date windowing. Basically, some developers of devices using GPS-derived time were aware of the problem, and put in a pivot so that dates from before the device was made are treated as being in the future. (e.g. a device built in 2009, ten years after the last time this happened with GPS might treat dates from the 1999-2008 time period as being in 2019-2028, since that's when the device would first encounter them)
So this may be causing random failures of devices for years.
-- This and all my posts are in the public domain. I am a lawyer. I am not your lawyer, and this is not legal advice.
Oh no, it's Y2K all over again!
Increasing the size of the number is the wrong thing to do... it just creates the same problem further away.
They need to shorten it to just 7 days. Then everyone will implement the roll over correctly vs just putting it off and forgetting about it.
Hope you have a bunker and supplies.
I have a few different cheap Chinesium GPS pucks. I am certain they cannot be updated, and if they really do change the message format to add 3 bits to the epoch, they will certainly stop working.
I wonder how many Chinesium smart watches and other consumer devices there are out there that will similarly get bricked for lack of support from the 'third shift.'
I can only hope the date string is interpreted by Google Maps itself, and not handled by Android or the handset hardware.
Imagine you GPS functionality becoming useless because you're not getting an Android update since the handset manufacturer considers your phone EOL.
Was it that difficult to use trigonometry for a GPS? What on Earth has any timestamps anything to do with it*? I've got a few of "old" devices (pre3, n9)... I will use their map apps to what happens vs my current phone.
* Logs, okay. One, may be, from the satellite `IT' pov.
I have been a member of the NTP Hackers team for 25+ years: As many of you probably know most reference clocks on the Internet are based on GPS timing receivers. The last time we had a week rollover a small percentage of Stratum 1 servers went temporarily offline, or they were marked as "falsetickers" due to announcing a date which was nearly 20 years wrong. Most servers were either unaffected or got back online shortly after.
The key here is that 1024 weeks is a short enough time span that most competent developers will realize that their (embedded or otherwise) product might still be in operation during the next rollover so they have to handle this, while a 13-bit week counter is so long (8192 weeks or 157.5 years) that it is likely that many will simply forget about the issue until it comes back to bite everyone in 2137. :-(
BTW, there are _many_ ways to handle rollovers like this, the easiest is probably to compile in the build date in your firmware and then simply make sure that the date calculated from the week number is greater than this, adding blocks of 1024 (or 8192) weeks if needed. Another option, if you have any kind of non-volatile memory, is to write the current date to permanent storage regularly, like once a month or once a year.
Terje
"almost all programming can be viewed as an exercise in caching"
After the widely publicised Y2K debacle, avoiding a similar scenario wasn't considered by GPS manufacturers at about the same time?
I have a timekeeping device next to my bed that uses just two bits and one trit (ternary digit) for the hour, so it goes back to zero every 12 hours. So far it has worked well without any firmware updates. Provided I remember to wind it up. I guess the people who designed it were cleverer than the people who designed GPS.
In the case here, assumption was that GPS firmware would know which window of 20 years would make most sense. A GPS designed to be remotely viable over a large timespan would generally have to have persistent writable storage for map data, so storing the current general 20 year window should be feasible.
Similarly, I seem to recall some man page back in the day defining the timestamp as being in terms of the 'current' epoch and explictly saying the epoch would change. Of course I don't think any agreement was made on how to denote the current epoch so I don't know what was expected of developers in terms of handling that tidbit in that man page. I suppose they presumed a consensus would be eventually reached and software could be updated to deal, since the hardware they were working on would definitely not be making it to 2038 anyway, so an epoch change is the least of their worries in terms of problems to solve to be runnable software in 2038.
XML is like violence. If it doesn't solve the problem, use more.
Why does it even need to send a week number? Don't they just do the time and satellite number, and they are all in as fixed a position as they can be so you just get 3+ signals and triangulate. Easy peasy. Where does week number come in and why is it relevant?
Wanna buy a shirt?
https://www.redbubble.com/people/stealthfinger/shop?asc=u
Who still uses GPS these days? Galileo was specifically developed by the European Union and the European Space Agency to address the threat posed by GPS. If you're still using the old standard, you have to expect this kind of thing. The Americans despise Galileo because they think it can be used to target their military forces. Maybe if they didn't lead the world in bullying, that wouldn't be a problem. Modernize and leave GPS behind.
Shutting down free speech with violence isn't fighting fascism. It IS fascism!
car manufacturers / dealers may charge $250-$500 for update
"10 bits should be enough for anyone" - US DOD
Space was seriously precious back then (a couple of meg of ram was huge, most systems were in the 128k to 256k range for memory), they chose 32 bit even though it wasn't easy to handle on lots of machines to give enough time for future versions to update it without hitting a wall immediately. And lo and behold unix time was updated to 64 bits years ago, so 2038 isn't an issue. The only unix things that will hit that wall are things that are either not dynamic (scripting language) or can't be recompiled with the 64 bit time_t size. With regards to Go, that is perfectly fine foresight, 250 years is plenty of time to change things as needed. You seem to be making the assumption that the world is static and unable to change. For all we know Go won't even be used in 100 years, let alone 250. Of modern languages only a handful have made it to 40 years still retaining wide usage (c, cobol, fortran, lisp variants, ...)
And by the way using 2 32 bit numbers is the same as using a 64 bit number, just more of a pain in the ass to handle.
Buzzword Bingo - Glider edition.
NeXTstep (and by extension OS X) uses a double float seconds since 1970 in its NSDate class. This not only avoids the Y2038 (and Y10000) problem, but gives you microsecond accuracy for dates that are inside the current era. There is also no floating-point round-off error for any whole number of seconds because they are the base unit.
The problem with using floating point for time is that the precision varies with distance from the epoch. Over the course of a century, this comes to 100 * 365 = 36500 or over 15 bits for representing (say) the number of days, which reduces the precision for fractions of a day by the same amount.
Conversely, if you want ns precision, 64 bits will only give you ~20,000 days, which is less than a century. But 128 bits will give you ~10^20 years at ns precision. Which should cover the big bang to the effective heat death of the universe...
You will not drink with us, but you would taste our steel? - Walter Matthau, The Pirates
I don't think I will buy a plane ticket on April 6 if GPS everywhere is going to fail.
any normal person and tech has switched to glonass long ago ,gps is for plebs
The problem with unsigned time were mentioned by another commenter here. There are medical applications that use signed 32-bit time for patient dates of birth. That's a problem in and of itself since some of those patients were born before December 13, 1901 (back when the software was originally written at least, this isn't a problem anymore). However, there are certainly still people who were born before January 1, 1970 tooling around. For them, you'll need negative numbers to represent dates of birth in UNIX time.
I made the date of birth comment... But for some products it doesn't matter. I'm working on one where time means "right now", and unsigned long works great for most of that. Some security layers are using 64-bit time. If I had designed the thing, I'd probably make sure that any external view of time was done in signed 64-bit; internally signed time would get rid of some pesky typecasts but otherwise there's no need for 64-bits there.
You sound as if you just want one format for all time uses. Except that it doesn't work, it doesn't take into account microsecond resolution that many applications need or even smaller in some domains. Different domains have different uses for time and trying to cram it all into a single standardized format doesn't always work.
Already we have to work with multiple time formats. I run across stuff I have to interface with that uses 2010 as the time base, stuff that uses 16-bits for the time-of-day (with the silly 2-second resolution that MSDOS had), stuff with no concept of daylight saving's time, and so forth. So having to deal with time is a part of job in some segments of embedded devices.