3 ms·

> 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://

by acqq 8y ago

> 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-failures-keep-happening-but-theyre-almost-done/ 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 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.

syockit 8y ago
I'm rather interested in what kind of software developed after Y2K still exhibiting Y2K bug, and how it affects the usage. Is it made with the assumption that it's going to record only post-Y2K dates, and somehow user manages to input pre-Y2K date?
- avar 8y ago
  A lot of software was never fixed for the Y2K problem. People just went from e.g. entering a date of 99 to 00 as the new millennium rolled around, and dealt with the pain of any time offset calculations being incorrect and needing to be manually fixed for a few months. 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.
theclaw 8y ago
> 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.
- fanf2 8y ago
  You don’t have to write that code yourself, you can just use libfaketime https://github.com/wolfcw/libfaketime https://github.com/wolfcw/libfaketime

by acqq 8y ago

syockit 8y ago

I'm rather interested in what kind of software developed after Y2K still exhibiting Y2K bug, and how it affects the usage. Is it made with the assumption that it's going to record only post-Y2K dates, and somehow user manages to input pre-Y2K date?

avar 8y ago
A lot of software was never fixed for the Y2K problem. People just went from e.g. entering a date of 99 to 00 as the new millennium rolled around, and dealt with the pain of any time offset calculations being incorrect and needing to be manually fixed for a few months. 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.

theclaw 8y ago

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

fanf2 8y ago
You don’t have to write that code yourself, you can just use libfaketime https://github.com/wolfcw/libfaketime https://github.com/wolfcw/libfaketime