There are a lot of reports of systems failing to understand the year 2010 but I've no idea why. Current systems I look after are working fine as far as I could tell but I'd like to know what the actual problem is to search better.
Could anyone shed some light on it please?
Edit: http://www.rte.ie/business/2010/0105/bug.html - Information about it affecting credit cards in Germany
I've got a system at work that uses a one digit year field. Yes. One digit. So the reason this system is failing is that "2000" is expressed the same as "2010".
The one I heard about was quick fixes people did for Y2K without thinking it through. So if xx < 10 then 20xx else 19xx.
One possible explanation is in the article below
http://www.theregister.co.uk/2010/01/05/symantec_y2k10_bug/
Reminds me of your recent article about cheap and dirty Y2K bug fixes where some unscrupulous programmers put in a simple if <10 = 20xx otherwise the date is 19xx
SpamAssassin had a rule to mark dates too far in the future as spam:
/20[1-9][0-9]/
The fix came a few days too late, but it's quite simple:
/20[2-9][0-9]/
See you again in ten years.
It might be due to the young developers who started their careers after Y2K and are using 1 digit to represent the year.
I took care of a little 2010 fail in a site last weekend, it was just the result of an oversight in coding though.
Someone thought it would be a good idea to set the value of a list item to the current dateTime.year.Now() when the list only contained items up to 2009.
ddlItem.findByText(DateTime.Now.Year.ToString())
Here is a screen shot of the norton symantec endpoint protection
Really nice that no one @ symantec informed their customers... Till the article was posted: http://www.theregister.co.uk/2010/01/05/symantec_y2k10_bug/
It is that there is a bug in a component that splits the year in two parts. The second part is used in a comparison so that the digit 10 is not in base 10, it's in base 16 meaning that it's 0x10 = 16 (hex).
Several protocols used in banking and telecommunications - including the SMS protocol - encode the year as BCD in a single byte.
From 2000-2009 one could easily make the mistake of interpreting the year as a standard binary number since the encoding would be the same:
Encoding Binary-interpreted BCD-interpreted
0x01 2001 2001
0x02 2002 2002
...
0x09 2009 2009
0x10 2016 2010
...
That is most probably the cause of the Windows Mobile bug.
I used Google Code Search to find y2010 bugs in open source software. I looked for one particular pattern that would indicate a bug (use of "200%d" as a printf format string), and found several projects with that bug. Creative application of search patterns could probably turn up more different kinds of bugs.