This might be mildly annoying for car navigation systems. But nothing compared to the potential danger for aviation: several published instrument approaches are now GPS-only!
Danger on approach is probably pretty unlikely. The vast majority of instrument approaches require the runway to be in sight before descending below an altitude minima. Where the approach is blind to touch down a higher level of equipment and procedures are required to verify the position and altitude. This could include checks against other data sources and monitoring.
I would really hope that something as critical as aviation instruments have the capacity to be updated to account for this and that it's been treated like a mini-Y2K with lots of fixes made ahead of time. But I guess we'll see...
I think the INS in modern airliners is actually accurate enough to not drift to the point of needing correction. INS + GPS exist to back up each other, and usually the pilot can switch between the two.
The data stream doesn't move very many bits per second, and it needs to keep saying the week number, so every extra bit you decide you want for that week number means that for pure GPS units (which don't have the Internet to go get the GPS metadata from, an Internet which also knows perfectly well which week this is) the time from power on to first fix is proportionally slowed as they wade through all those extra bits you just felt sure they needed.
"On the downside this will take 40 minutes to tell us where we are, on the upside trampeltier feels better about it"
Also your driver probably doesn't use 500MB of RAM, more likely it wants 500MB of address space, and address space is basically free on 64-bit systems anyway so who cares?
Your argument that the space is sparse is true though in the new protocol which has still a message of 300 bytes but no reserved space any more: https://i.imgur.com/xyxCxIi.png
It gives 13 bit to the message at least, making the counters roll over every 157 years instead of every 20. It's still a bit too little IMO. Date counters should either be so short that engineers must design rollovers into the devices (e.g. 1 year) or longer than human lifespans by several orders of magnitude (e.g. 1000 years).
> certain LTE chipsets have an OFFSET WEEK... and they haven't hit 1023 yet. Oh no. According to what I've managed to dig up, they're going to hit it 2019-11-02 at 23:59:42Z.
Any sources? What is an OFFSET WEEK? Why do you call it "GPS week number rollover" when it is affecting LTE chipsets?
Do LTE chips also support GLONASS and BeiDou, or do phone makers have to install a separate chip for those systems that Android phones commonly drawn on?
If you're looking for another source, Apple released iOS 9.3.6 and iOS 10.3.4 to fix the same bug: https://support.apple.com/en-us/HT210239, which will stop working correctly on November 3rd if not patched.
From my experience (we had to change/fix a couple thousand devices in my company), some gps modules simply stopped reporting valid positions, returning just all zeroed.
The coordinates are derived from the timestamp and satellite location - that's how GPS systems work.
All the satellites have the exact same time. But deviations in the timestamps when received (because the speed of signal is constant) help the receiver calculate it's own position.
It was mostly a theoretical problem and not something I went through with.
I only thought about it because I was also saving the expiration in a session table in mysql and my expires column is a `timestamp` which is 4bytes. I was using a language that uses more than 32 bits for dates, so you're right, it probably would've sent out the right cookie.
It's bad enough supporting browsers from 10 years ago now. If we get to 2038 and I still need to support browsers from 2019 I'm going to be very sad indeed.
What is your target? I work in embedded systems: I fully expect software I write today to run for the next 100 years. This is based on experience, we have customers still using 75 year old machines to do real work (that is not collectors) and I like to think engineering has learning something about making better machines since then. I think that computers will forever be able to drop back to 10baseT ethernet, ipv4 and html 1.0.
Of course I don't expect everybody will be able to support those configurations. There are currently unknown security holes someplace in out old equipment so nobody sane will connect our old stuff to the public internet. Thus most developers are safe depending on users having something fairly new. However a few will target behind the firewall customers and they will be stuck supporting whatever that old machines supports.
Perhaps it is because whoever came up with the specification for "browser cookies" never intended them to not expire, and thus you are trying to subvert the feature to do something it wasn't meant to.
The Jurassic Park quote comes to mind: "Your scientists were so preoccupied with whether or not they could, they didn't stop to think if they should."
Reminds me of how NASA wouldn't fly the Shuttle over New Year's day to avoid rollover issues: https://www.newscientist.com/article/dn10459-y2k-like-fears-...