
Older GPS devices are facing their own mini Y2K bug next month - ohjeez
https://www.theverge.com/2019/3/8/18255847/gps-week-rollover-issue-2019-garmin-tomtom-devices-affected
======
strenholme
I actually have written code like this to deal with the Y2038 problem UNIX
will have (for UNIX systems that still use a 32-bit time_t on January 19 2038,
they will roll over and think they are in 1901) by seeing if time_t is 32-bit
(my code uses 64-bit numbers for timestamps). If so, it will assume we're past
2038 and not before 2007 if time_t is a time before 2007. This moves the Y2038
problem to 2143, at which point hopefully there will no longer exist anything
which uses a 32-bit time_t.

One bug caused by this is that embedded software developers sometimes started
my daemon _before_ setting the system time, which caused issues because my
code thought the year was 2106 (and not 1970). My answer was to tell the guy
to always set the time before starting my daemon. I could also make the death
date 2106 (instead of 2143) to stop developers from doing that, but I'm not
getting paid enough to protect people making money from my volunteer work from
their own stupidity, and adding 37 years before it stops working makes it that
much more likely anything and everything using that code will be gone before
there are issues.

~~~
thisacctforreal
Your use of parens in the first sentence made it difficult for me to parse.

------
makomk
Probably not that many devices, at a guess. We've already had one GPS week
number rollover and most GPS hardware now handles it by assuming the current
date is after the firmware was released (so they'll mostly break 19 and a bit
years after the last firmware release, not on the rollover).

Oh, and this also means that some devices have had rollover-related issues
before the actual rollover date. Some of the early, out-of-support Trimble
devices apparently haven't been able to get the right date since 2016 for
example.

------
ambrop7
So is the date info from GPS ambiguous because of the roll-over - a device
cannot tell what the date is based solely on GPS without having some prior
info (e.g. its own internal clock)?

