anyone for a date

Great Christmas holidays are oft followed by despair.

This year was no exception. Fancy discovering a couple of days before a manufacturing plant starts up for the new year that a bug has been hiding since 1998 to show itself. During a system upgrade in 1998, one developer had decided that handling a 2 digit year in an incoming file transfer would only require checking the first digit to determine which century it lay within. Consequently, with the new year rollover to 2010, we found ourselves back in 1910. A problem on a couple of counts.

One, it lay before the UNIX epoch of 1/1/1970 and two, it was out of range of our now legacy third party real time database.

An easy thing to fix, followed by a full system build and release on a Friday afternoon, all ready for a weekend startup.

But it has now exposed a bigger problem, the UNIX end of signed 32 bit date problem, that some say may be known as the UNIX millenium bug or the Friday the 13th bug due to the date rollover to Fri Dec 13 20:45:52 1901 when the date happens to hit Tue Jan 19 03:14:07 2038 UTC.

A potentially larger problem due to the total number of impacted systems across the planet included many that are embedded.

Many references to the problem, particularly at http://www.2038bug.com/ with some interesting predictions about the response that I have extended with my own thoughts and descriptive language.
- lazy programmers wait till the last minute to fix the problem through lack of incentive or management pressure
- smart programmers use the problem to create another dot com frenzy and the sharemarket hits new highs
- the media blows the problem up into a doom and gloom scenario where even the most basic social structures will break down, all without the benefit of a zombie attack
- terrorists direct their attention to fostering the installation of as many bug prone systems as possible in the hope of the mother of all meltdowns.