The 787 didn't even exist when the GPS time last rolled over, so it's quite unusual to see it have this problem --- unless Boeing reused the software from a previous version, which is not surprising given the regulations of the industry, but that would imply other older models also have the problem.

> The 787 didn't even exist when the GPS time last rolled over, so it's quite unusual to see it have this problem

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.

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

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.