Look out for the second 2019 GPS week number rollover | Hacker News Reader

Look out for the second 2019 GPS week number rollover

rachelbythebay.com

83 pointsweinzierl29 comments

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!

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-...

I thought most airplanes have Inertial Navigation Systems with GPS for occasional calibration when the INS drifts.

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.

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...

You would hope that it would have happened ahead of time: https://arstechnica.com/information-technology/2019/04/gps-r...

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.

The "fancy" sound driver on my companys HP ZBook does use 500MB Ram but a few bytes for a correct date are still to expensive ...

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?

There's plenty of reserved bits in the old protocol to give more bits that the 10 the WN (week number) already has: https://i.imgur.com/QuJDwmb.png

Source: Figure 20-1 in https://www.gps.gov/technical/icwg/IS-GPS-200K.pdf

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

Source: https://www.gps.gov/technical/icwg/IS-GPS-705F.pdf

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?

GPS is integrated in LTE chips, so you don't need another one just for GPS.

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?

https://www.qualcomm.com/products/qualcomm-9205-lte-modem

The Qualcomm® 9205 LTE modem is our next-generation ...

Qualcomm 9205 uses the latest generation (gen9) Qualcomm® GNSS engine ...

Location

Satellite Systems Support: GPS, GLONASS, Beidou, Galileo ...

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.

My understanding is that the only bad thing that will happen is that the GPS will show the wrong date (I think the time will still be correct?)

The coordinates will still be correct.

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.

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.

I was recently trying to set a cookie to "never" expire.

Apparently there's no good way to do this other than pick a date that's far enough out in the future.

A stackover answer gave an example setting it for 10 years. I thought I would be defensive and set it to 20 years.

But then it will immediately break because 32 bit dates wrap around in 2038!

Just set it to 1000 years, browsers have been able to handle such cookies for as long as I can remember.

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."

The format for "Expires" is e.g. "Expires=Tue, 15 Jan 2013 21:47:38 GMT".

Why would that wrap around in 2038? Are you assuming that browsers handle this incorrectly?

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.

> But then it will immediately break because 32 bit dates wrap around in 2038!

Do modern browsers still use 32 bit timestamps internally?

Regardless, it's probably not a good idea to rely on the browser saving cookies forever.

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.

You'll still need to support browsers from 2009 ;)

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.

After watching a few Def Con talks, I' am sure there is a good chance of a very dedicated asshole out there trying to target those old systems.

This has kept me awake at nights for years... It is now keeping boards of directors up at nights unlike a few years ago when I was told not to worry.

No solution is in sight, but things are getting better.

I am impressed of the idea of using the same browser (and cookie store, related OS, whatever) for 20 years ...

Reply on news.ycombinator.com