Nevertheless, Feb 29 and March 1 are easier target dates than Feb 1, March 31 or Apr 1 or july 1. I suspect rare longer-period jobs (monthly, quarterly, etc.) will show one of the highest ratios of in-field downtime to pre-remediafion bugs, simply because most organizations have had to focus testing effort around jan 1 and Feb 29. Often putting expensive test systems through the many other conceivable failure dates simply could not be cost justified. At last, perhaps sometime in 2001 or 2002, most of the Y2K bugs will have been found and fixed. At this point we can begin thinking about the 2011 bugs, the 2038 bugs, and so forth. It seems absurd to think that the versions of Microsoft Excel which incorrectly represent dates past 2011 will still be in use twelve years from now, but it seemed absurd to us two or three decades ago that any of the mainframe systems of the time would see the millennium. Most absurd of all is to think that the new, modem, replacement languages and operating systems of the present have similar structural date bugs built into them. Yet quite a few flavors of C, Unix, etc.,
/lp/association-for-computing-machinery/y2k-and-apl-an-overview-dwd5V5qNlX