In 22 years, any unix/linux platform still using 32-bit timestamps will overflow:
From Wiki:
At 06:28:16 UTC on 7 Feb 2036, Network Time Protocol will loop over to the next epoch, as the 32-bit time stamp value used in NTP will overflow.
At 03:14:08 UTC on 19 January 2038, 32-bit versions of the Unix time stamp will cease to work, as it will overflow the largest value that can be held in a signed 32-bit number (7FFFFFFF16 or 2,147,483,647). Before this moment, software using 32-bit time stamps will need to adopt a new convention for time stamps,[19] and file formats using 32-bit time stamps will need to be changed to support larger time stamps or a different epoch.
At 06:28:15 UTC on Sun, 7 February 2106, the Unix time will reach FFFFFFFF16 or 4,294,967,295 seconds which, for systems that hold the time on 32 bit unsigned numbers, is the maximum attainable. For these systems, the next second will be incorrectly interpreted as 00:00:00 1 January 1970 UTC.
ping
There is something unsettling about having to “re-boot” the airplane
From what I’ve read, this software issue only applies to 25 planes assembled. Boeing has said all the newer 787’s don’t have this issue.
Sounds like sloppy programming to me... And poor QA/QC processes. You should always check for these sorts of errors, grab them, and act accordingly. You just don’t let the program die or freeze up on these sorts of systems.
I read the article and nothing was said about if this was a cumulative counter or a re-settable counter. First of all, no plane flies for 248 consecutive days and secondly, there are multiple service time maintenance requirements for transportation aircraft. So, for me, not flying a 787 for this reason is nonsensical.
What the real import of this issue is comes from guarding against a single-point failure that generates a fatal situation. For the 787 example this could be as simple as checking airspeed before engine shut-down. The obvious problem is the number of such potential failures grows as our software becomes increasingly useful. CATCH-22 in real life!
I can’t imagine engines being on continuously for 248 days.
Great article. I wish the author had mentioned the mother of all computer overloads, which happened during the decent of Apollo 11 to the lunar surface:
https://www.hq.nasa.gov/alsj/a11/a11.1201-fm.html