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=-
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
Hope you have a bunker and supplies.
13 bits of weeks = 157.5 years. It's safe to assume there will be entirely new navigation systems by the year 2175.
How can I believe you when you tell me what I don't want to hear?
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.
That's what the developers in 1978 also assumed. There is an old saying in engineering: Nothing stays around as long as an interim solution.
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
You don't know the angle to the satellites. What you know is the run time difference of the signal. You have to compute the distance from that, compensate for things like the impact of gravity and after all that, you can do compute the intersection of the spheres.
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.
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
The 13-bit week number is in a completely different message format broadcast using different modulation. Using that signal will require completely new hardware, not just a firmware update. But they're likely to keep the current '70s-style signal around for a couple of decades yet.
At this point there is no reason any system should be using anything less than a 64bit value for time moving forward. I can sort of understand the limitations from back in the day and trying to save resources. Although making one integer smaller is not going to save you anything measurable even on a system from the 70's. Its one integer. But with 64bit processors and OS's being the standard today there is no reason time should be kept in anything less. Its probably overkill to make it more than that but that wouldn't necessarily hurt either.
car manufacturers / dealers may charge $250-$500 for update
"10 bits should be enough for anyone" - US DOD
Buzzword Bingo - Glider edition.
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.
Never worked in a shop that makes commercial hardware have you? The pencil pushers driving those guys are still clawing back every bit they can in order to use a chip that is one copper penny cheaper.
Aah, change is good. -- Rafiki
Yeah, but it ain't easy. -- Simba
Early computers were designed with the same mentality. "The year 2000 is WAY off."
It little behooves the best of us to comment on the rest of us.
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
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
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.
Some have addressed the problem long ago. For example Microsoft fixed visual studio over a dozen years previous to have time_t be 64 bit for 32-bit and 64-bit software.
Others have elected to do nothing. time_t is still 32 bit in present day 32-bit Linux systems.
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.
At this point there is no reason any system should be using anything less than a 64bit value for time moving forward.
So you're saying it should take over a second to transmit the time? GPS has 50 bps data rate (100 bps in some configurations) according to table #1 at https://gssc.esa.int/navipedia.... I'm pretty sure there are other circumstances such as communicating with Mars or further or a submarine deep down with low bit rates as well.
Although making one integer smaller is not going to save you anything measurable even on a system from the 70's. Its one integer.
In 1984, Apple released the ProDos disk operating system which packed day, month and year into 2 bytes to save room. I'd guess going further back that packing more then the date into an integer happened as well as systems such as the PDP-1 that used 6 bit bytes.
https://en.wikipedia.org/wiki/Inverted_totalitarianism
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.