Uh... this sounds like an urban legend to me. The dateline appears on maps, not in the air.
I can't see how it would have any effect whatsoever.
It's amazing how people will believe anything they read, even if it is just on some blog.
I can't see how it would have any effect whatsoever.
Whether they returned to Hawaii for this exact problem or not, fact it they did have to return for some software glitch.
The dateline has exact latitude/longitude coordinates, which the GPS and (if the F-22 has it) inertial guidance would feed into the system. I can see this event actually happening.
Like someone else above - its is stunning that there isn't at least a rudimentary set of analog backups on the F-22. But then, your have to assume they would be useful by the new breed of pilots - I wonder if they have the training to fly anything but a computer controlled, glass cockpit rocket!!
Look'ie there Flash, that dial is round
Daily Tech LLC got the story from CNN, which broadcast it on Saturday (according to the transcript). That's not a great recommendation (IMO) but make of it what you can.
This was initially reported about a week ago. They did indeed return to Hawaii, but news reports of the time just said "software glitch".
I write navigation software for a living, and I can certainly see how the issue came up. It's not the "date" part that's the problem it's crossing from latitude -190 to +190. Kind of like a Y2K issue, except this one happened for real. Basically any map they had would have a reversal of sequence within the same map, which could cause any number of issues.
The part that worries me is that they lost so many sub-systems, like fuel, etc. Or perhaps they merely lost their display of those indications, while the hardware functioned merrily on it's own.
I can't see how it would have any effect whatsoever.
Upon crossing the IDL your GPS is going to give you a big jump in time and the longitudes may change signs. I can see a glitch in there.
If the onboard software uses GPS to calculate local time, that could have a ripple effect. It does seem odd, though, that the subsystem displaying local time -- which is a luxury, not a necessity, as Zulu time works fine -- would be tied to the other code intimately enough to bring critical systems down.
It's probably about data checking. A subroutine should never trust the data it gets, but still programmers make the mistake of trusting it. "The data is coming from the system itself, so why not trust it?" Big mistake. Let's say the navigation system uses local time data for its operation. Suddenly the date on the time jumps forward by one, the subroutine freaks out due to the unexpected change and crashes. What I don't understand is why the system isn't built modular so that the navigation system could just be restarted.
True story: Recently a guy was using the in-flight entertainment system of an airline, setting up a game of Tetris which allowed you to set the number of future pieces you can see. The maximum allowed value of 4 using the arrows on the screen. Then he used the seat phone, and it accepted an input of 5 from there (but nothing above 5). Looks like a programmer wrote "It's okay if it's less than or equal to 5" instead of "It's okay if it's less than five."
Not too big of a problem, except the the guy was able to use the up arrow keys to then go higher, where he was normally stopped at 4. Looks like the programmer wrote "Don't go higher if it equals 4" instead of something like "Don't go higher if it's greater than 3."
So, having bypassed the initial bounds check and unrestrained by another poorly written one, he kept hitting the up arrow until it hit 127, and next after that in a signed byte is -128 (it rolls around to negative). A negative value where a positive is expected down the line can have serious consequences, like out of bounds or data type mismatch. He hit up again, it briefly showed -128, and *poof* went the entire in-flight entertainment system. Everyone's screen went blank.
It's amazing the consequences a small bug can have.