It's not as unusual as you'd think:
https://blog.fosketts.net/2019/04/06/gps-time-rollover-failu...
There you see a nice summary of the problem and an example a Mercedes car from, if I understood, 2008 experiencing the same type of problems. Also discussed on HN:
https://news.ycombinator.com/item?id=19593227
It's like having a Y2K bug software and saying "but that software didn't exist before 1900." It doesn't matter when the "epochs" are, it's just about what the design covered or didn't.
I've personally fixed the trading software which failed to correctly implement the correct rollover of the decades (i.e. the transition from year 9 to year 0 in the names), not to mention Y2K. It was simply tested before only "in the same decade."
It's definitely a failure in the development process, for the software that is supposed to work in some bigger time frame, and not only shortly.
Some of it's doubtless still in use and people are entering "19" as the year today, and if it's still in use in 2099 we'll have the exact same problem all over again with the exact same software.
That may seem crazy today, but people in the 1950s would have thought you were crazy if you said B-52s were still going to be flying in 2020.
There's doubtless going to be people still running Windows 95 on some emulator in 2100 to use some legacy application that keeps chugging along. Some software we use today might be in use for thousands of years or more, unlike airframes it isn't subject to any natural decay or wear.
This is why I've recently started abstracting time/date calls in all my work so that I can test using arbitrary dates/times rather than using the various "now" library calls directly.
This has already had the side-benefit of allowing me to deal with stuff like the time arbitrarily going backwards when NTP synchronises the clock. I don't typically rely on wallclock time for sequencing, this just keeps things a little more robust.