IT media sources are reporting that reports of the demise of the Y2k bug may have been premature. (see also here)
Systems affected included Spam control software and other security software from a leading vendor, network equipment from leading vendors as well as credit card payment systems in Germany and Australia, as well as (it seems) Windows Mobile. The bug was tweeted heavily on Twitter.
The effect of this bug seems to have been to catapult messages forward in time by a few years, resulting in credit card terminals rejecting cards as they failed date validation checks (the card expiry date was in the past apparently), valid emails being flagged as spam (because the message was date stamped in the future), and SMS messages appearing to come from the future.
The potential knock-on impacts of this error don’t bear thinking about. In the immediate term we have:
- Embarrassment for credit card wielding shoppers who found themselves unable to pay for purchases or meals.
- Missed emails due to them being flagged incorrectly as SPAM (although this has been fixed).
- SMS confusion.
But, in this automated world where processes are triggered by business rules based on facts and information there are potentially other impacts:
- Discovery of emails or SMS messages in criminal or civil litigation (will the lawyers think of looking in the future? Can the evidence be verified if it appears to be from the future?)
- electronic transfer of data or funds based on rules
- Calculation of interest payments or penalties based on date rules
The root cause of this problem appears to have been assumptions about dates, and the thought in 1999 that 2010 was sufficiently far in the future that (one must assume) everyone assumed that a better fix for the rules being applied would be developed by then.
Daragh,
I predict the Y2K bug will rear its head on an annual basis…
Here’s why:
A popular Y2K “solution” in enterprises with large quantities of legacy code and legacy data was (and remains) the “windowing solution”.
The “windowing solution” reads a two digit date (YY) from a database and prefixes it with a century (either “19” or “20”), thus returning a four digit date.
There is a “window” of just 99 years… and the “window” was set to many different ranges.
in 1999, a “window” may have been set as follows:
Prefix years “10” to “99” with “19” (giving 1910 to 1999).
Prefix years “00” to “09” with “20” (giving 2000 to 2009)
In the above scenario, when the new decade dawned, the windowing solution went from “2009” to “1910”… need I say more?
“Advanced” forms of the windowing solution may include automated adjustment of the window – but I doubt there are many of those.
You are probably correct in your suspicion that people assumed that the system(s) would have been replaced before 2010…
The reality is that “Old hardware goes into museums, while old software (and old databases) go into production every day, and every night “.
Rgds Ken
Pingback: Information and Data Quality Blog Carnival, February 2010 « Liliendahl on Data Quality