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.
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.
Anything stolen, lost from the US mil that needs a new upgrade won't work :)
Domestic spying is now "Benign Information Gathering"
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!
Before posting judgmental crap like that, you should know your history: the Global Positioning System project was launched in 1973, and the first satellite went up in 1978. The design was done sometime in-between.
Well guess what: in the mid-seventies, EVERYBODY was coding stuff without thinking it'd still be there 40 years later, saving bits and CPU cycles everywhere they could thinking X or Y weeks / years / kilobytes / megahertz should be enough. Even the long-term thinking Unix people thought 2038 should be far enough in the future.
"A door is what a dog is perpetually on the wrong side of" - Ogden Nash
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.
GPS designed long before Ive was designing anything. Your irrational hatered is tres amusement
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.
Except none of the current GPS satellites are from the 70s.
Ok, why do we learn about its bugs and defects today? Every piece of ugly shit has a gps chip by now.
But the protocol ans message format was designed in the 70's, so even if the satellites are newer, they still have to be compliant with the initial protocol specifications.
With Unix they didn't really pick 32 bits as being "good enough", it was just the largest they could easily handle at the time.
With GPS they probably just assumed that the military would update or replace receivers when necessary. Civilian use wasn't a major concern, and due to the cost of the equipment they probably didn't consider the use-case where every cheap $10 smart device from China has a GPS receiver in it.
const int one = 65536; (Silvermoon, Texture.cs)
SJW, n: "Someone I don't like, and by the way I'm a fuckwit" - AC
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.
Some programmers are STILL designing stuff with the assumption something won't still be there 40 years later. The DVB standard has a roll-over date in 2038 (that's a project created in 1992 no less!) and Go has UnixNano which has a rollover date in 2262 (because of course the graybeards that gave us the original 2038 bug and unsafe arrays couldn't build a decent language the third time). BTW you don't need a 64-bit number to have dates that go beyond 2038. You may need 2 or 3 32-bit numbers too It's all a matter of formatting. All these time storage bug were a result of massive lack of foresight. Also, Go uses a single 64-bit value to count nanoseconds from epoch (*sigh*). Now that's some lack of foresight that you don't see every day.
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?
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.
#naabhaprzrag, #sverubfr-000, #agi-fcbafberq, negvpyr[pynff*=' negvpyr-ary-'] { qvfcynl: abar !vzcbegnag; }
And as usual the best technology didn't make it. Oh well, at least this state of affairs will keep us computer people employed.
Missed the OS X part. Sometimes I forget significant part of OS X is NextStep. Anyway, still a minority OS.
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
car manufacturers / dealers may charge $250-$500 for update
Ah, yes, the ever present "we're holier then thou" attitude of others outside America who think they are better then us. *Shrug* However, it's always better not to care what others think, if you do you end up becoming a slave to their perceived intelligence.
"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.
Why listen for ~24 satellites when you could combine their signals and listen to ~60?
I believe this is similar to the Y2K problem in computers (I am admittedly not an expert), the fix for which delays another event until 2038. That bug isn't about bad programmers, it's about programmers using a register size that seemed reasonable and worked within the limits of the hardware they had at the time.
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.
There's no reason for a programmer to code fir something that is expected to happen after his retirement.
For most uses, isLeap = (year % 4) == 0 is good enough :-)
With Unix they didn't really pick 32 bits as being "good enough", it was just the largest they could easily handle at the time.
They didn't pick 32 bits they picked 31.
Signed int is 32 bits. They went with signed because it makes it possible to detect overflows because the number goes negative, although interestingly that's not actually guaranteed by the C spec which says it is technically undefined.
const int one = 65536; (Silvermoon, Texture.cs)
SJW, n: "Someone I don't like, and by the way I'm a fuckwit" - AC
Signed int is 32 bits.
Relevance?
Y2038 exists because people elected to use only 31-bits to address time.
Using 32-bits to address time delays run out until 2106.
They went with signed because it makes it possible to detect overflows because the number goes negative
This line of thought was a bad idea then. Today it amounts to nothing short of willful negligence.
32 bits works even longer if you make it unsigned. For uses where you don't have to worry about things in the distant past, this is fine and trivial to implement. This is really helpful for the hordes of 16-and 32-bit embedded systems out there. Certainly 64-bits would be better for newer products, or anything between 33 and 64 bits (say you're on an 8bit cpu and would prefer 5 bytes instead of 8). You can also tweak the epoch start time to not be 1/1/1970 as well, if you know your time format will only stay local to the device, then converting between the device time and Unix time is a simple addition.
For something like GPS where you have data transmitting over the air then going to 64-bit is a waste of bandwidth. If you're talking to a Mars rover, then the extra bits are a serious disadvantage. So instead you rely on having good documentation of the format and that you can convert to other time formats as needed. Since we've known that GPS times will rollover in a relatively short period of time (ten years is shorter than many expected product lifetimes) you would assume that the receivers know how to deal with this. The problem is not that everyone needs to update firmware, but that you need to check if you have a halfway decent GPS receiver versus a piece of junk designed by noobs.
They originally used this format for file timestamps, so it was unlikely to ever have file's created or modified before 1970... It was after this point that people started wanting to use this format for all sorts of uses for which it was not suitable. Ie, I worked on a medical device that initially used this signed 32-bit time format for medical records; but that was a problem since you couldn't express some patient's date of birth, whoops.
Much of the problems come from blind reliance on third party libraries, or naivete about domain knowledge. They expect that they don't have to worry about such issues if they only call the appropriate library. It's only later that they discover that the library wasn't intended for what it was being used for. I am seriously amazed at how many experienced programmers don't know much about time and yet seem to think that it's simple and that anyone can do it.
I don't think the time formats had a lack of foresight. They were used for particular uses where it made sense. What broke was when people took the original signed 32-bit file time format to use for other purposes. Ie, purposes other than the file time on a specific PDP filesystem implementation. But it slowly got standardized in many file systems, the function calls dealing with time got standardized, and the file timestamp format started being used for things other than file timestamps. The original Unix system is no longer in use, their assumption was entirely correct and it isn't around still after 40 years later except as simulations.
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.
The macOS X epoch is actually 12am, 1 Jan 2000 :-)
Sounds like one of those width of a horse's ass situations.