Older GPS devices are facing their own mini Y2K bug next month

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.

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.

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)?