Perl and the Y2k problem
As the clock draws us relentlessly closer toward 2000, the final year of the second millennium, doomsayers everywhere are prophesying unprecedented computer failure in every conceivable sector. Known popularly as the Year 2000 Problem, or the Millennium Bug, this situation is quite easy to explain. Programs that interpret two-digit dates in the form XX as 19XX behave unpredictably starting in the year 2000 and beyond into the next millennium. If your birthday is ``2/2/05', are you 101 years old in 2006, or just one year old?
Cost estimates for fixing this bug range well into the billions of dollars, with the likely threat of at least that much money again incurred in protracted legal fees due to real and alleged damages. Because of these devastating cost projections, corporations and government are mounting pressure to secure legally binding statements that all software they use is warranted to be year 2000-compliant.
As you might well guess, this pressure often stems from lawyer-wary insurance companies, who quite reasonably fear death-by-litigation even more than they might the effects of costs of actual, incurred damages. To defend themselves against legal perils, organizations all over the world are rushing to secure, with all possible haste, affidavits to the effect that such-and-such software is year 2000-compliant. They intend to brandish these as some sort of legal shield when the inevitable chaos strikes, righteously proclaiming themselves free of Y2K taint and redirecting lawsuits toward the signers of the aforementioned documents.
Remember this: if someone asks you to warrant that your software is free of year 2000 bugs, they're really just looking for an excuse to sue you if they misuse your software, even if it should happen to be their own fault. Probably they've already forgotten the terms of their software licence, one which probably read something rather close to the following:
IN NO EVENT SHALL THE AUTHORS OR DISTRIBUTORS BE LIABLE TO ANY PARTY FOR DIRECT, INDIRECT, SPECIAL, INCIDENTAL, OR CONSEQUENTIAL DAMAGES ARISING OUT OF THE USE OF THIS SOFTWARE, ITS DOCUMENTATION, OR ANY DERIVATIVES THEREOF, EVEN IF THE AUTHORS HAVE BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. THE AUTHORS AND DISTRIBUTORS SPECIFICALLY DISCLAIM ANY WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, AND NON-INFRINGEMENT. THIS SOFTWARE IS PROVIDED ON AN ``AS IS'' BASIS, AND THE AUTHORS AND DISTRIBUTORS HAVE NO OBLIGATION TO PROVIDE MAINTENANCE, SUPPORT, UPDATES, ENHANCEMENTS, OR MODIFICATIONS.
The anxiety about the Y2K situation is reaching an increasingly feverish pitch in most large organizations. Every few days, you read something else in the popular media forecasting certain havoc. Nearly all these reports are peppered with vague prevarications or technical confusion. That's not to say that there isn't a real issue here, and that we can go pretending there's nothing to bother ourselves with. There certainly is. But what that problems stems from, and what can be done about it, is something usually misunderstood at best. Three commonly repeated lies exacerbate the situation. Did you ever stop to wonder just how long an automobile manufacturer might survive government scrutiny with such an anti-warranty? Why should software manufacturers be any different? Somehow, though, they do appear to be. Whether such things survive the courts in the litigational feeding frenzy certain to ensue in a couple of years is something that remains to be seen. Don't count on anything.