Fighting a 30-year-old software bug

My first thought was, "I remember this. Blame Joel Spolsky:" http://www.joelonsoftware.com/items/2006/06/16.html (well maybe not blame, it's a tradeoff.)

But he mentions it at the end.

Classic example of why greenfield development is much more pleasant than dealing with legacy systems. Of course, you have to do your new dev well to prevent it from becoming a legacy system that you have to fight with...

But I do think the world of development is just soooo much better now that it was 10 or 20 years ago. We, as a profession, have much to be thankful for.

Given Excel's popularity in the business world, I wonder if an exploit of some sort could be built into scheduling a transaction for February 29th, 1900. The date exists in Excel, but not the real world.

Related anecdote: Interestingly enough, Excel doesn't support dates prior to the "Excel epoch". I had some genealogical spreadsheets that I had to move to Google Docs from Excel because Docs supports arbitrary years and Excel treats anything prior than 1900 as strings instead of dates, losing the ability to perform date/time operations.

Sometimes I feel guilty for not insisting to use 64-bit time stamp for company's products. Hope anyone keeping those gadgets long enough to hit year 2038 would get sufficient fortune.

How old is the bug? The url says 20 the link and header both say 30.