I found an interesting example of what data is the most important of all: time. How it's recorded, calculated, accounted for, etc. is vital to the health and well-being of any information system and the applications and people that depend on them.
It is often the most innocuous and innocent of bugs and flaws that causes, or has the potential to cause, great harm and loss. Our example today is the much vaunted F-22 Raptor fighter plane. This baby is so advanced, it blew older fighter jets out of the water in simulated war exercises. They also cost $125 million USD each. Not a cheap machine, by any measure.
Recently, 6 of these were en route to Japan from Hawaii with tanker escorts. All was fine until they crossed the International Date Line. As the Daily Tech article relates:
When the group of Raptors crossed over the IDL, multiple computer systems crashed on the planes. Everything from fuel subsystems, to navigation and partial communications were completely taken offline. Numerous attempts were made to "reboot" the systems to no avail.
Luckily for this group, the weather was clear and they had the tanker escort lead them in the limp all the way back to Hawaii. Had the weather been poor, or the units in a combat situation, the outcome would have been much more severe and perhaps grave.
The problem was traced back to a very small segment of the 1.5 million lines of Ada code that runs these planes. After identification, the problem was fixed, and all is expected to return to normal operations.
There are similar time issues on the business side of things. I know of numerous organizations that spend much time, money, and hand-wringing "fixing" systems (primarily legacy) twice a year when the time shifts from daylight savings to standard and back again. they think they have the problem solved at these 6-month intervals, but then something else happens during the next switch. This time around they can add the fact that DST happens earlier beginning in March. The smarter ones have adopted Universal Time Coordinates (UTC) as a date/time standard as legacy systems are replaced. UTC plus-or-minus an offset for timezones is the only reliable way of figuring out what time it is. And those values are more important than a lot of people believe.
Time data and operations should be basic blocking-and-tackling for every development group. When time issues get trivialized or overlooked, the "soft underbelly" of a system will be exposed sooner or later, and the consequences could be severe, even tragic.
And not to be left as afterthoughts or to very junior development staff.