One of the biggest anticlimaxes of the century...
You guessed it - the Y2K "bug", as it's popularly being called these days.
If you listen to the doomsayers, everything thing from your teakettle shattering to the
end of the world is coming because of this "bug". Such a big thing from such an innocent foresight.
The Y2K problem stems from early programmers' usage of 2-digit year fields instead of 4-digit
year fields. While there are theories why they have done this, the most popular reason was to save
space on the computer. Other popular reasons were laziness, lack of foresight and an all-out booboo.
This 2-digit year problem is not new. While a huge deal is being made of the year 2000, this
problem has been rearing its head periodically throughout the last 20 or so years, typically with people
born before 1900. If someone were born in 1893, are they 106 or 6? So why haven't companies corrected
this potential problem before then? Who knows?
One main problem with the Y2K problem is the individual's reaction to it. When a group of people grow
fearful and panic, that's where the real problems occur. Not completely unlike a bank run, where bank
account holders were fearful of the failure of the bank where they're money's deposited, so they
withdraw all of their funds. Invariably, the removal of everyone's money from the bank will cause the
bank to fail.
So now that everyone's in a scramble to correct their Y2K problems, here's a message for Perl
programmers and users:
Don't touch your Perl code - it's already Y2K compliant!
As Tom Christiansen eloquently put it "…Perl is every bit as Y2K compliant as is your pencil;
no more, and no less…". Perl by itself has no Y2K issues. Programmers "break" their programs and
will cause the Y2K problems.
Perl's two date and time functions, gmtime() and
localtime() functions return the number of years since
1900. So basically, when the gmtime or
localtime functions are called, it will return the current year
minus 1900.
So, let's consider the following popularly used code:
($sec,$min,$hour,$day,$mon,$year,$wday) = localtime(time);
$year += 1900;
Now most people would look at this code and say "aha! It's not Y2K compliant -- change the 1900 to 2000".
Don't! Let's break this down:
Let's say that the current year is 1999. Using the first line of the above code,
localtime will return the current year minus 1900, which
means that 99 is returned to $year. After that, to get the 4
digit year, we add 1900 to it (in the second line).
You're probably wondering what happens at the turn of the century? Easy. What's 99 plus 1? That's
right - in 2000, the localtime and
gmtime functions will return 100. So does
$year += 1900 still work? You bet.
1900 + 100 = 2000.
Because the above code is fairly well propagated throughout many existing cgi programs, the problems
come in when an unseasoned programmer looks at the code, says "aha!" and decides to make it Y2K
compliant by adding 2000 to $year instead of 1900 like so:
($sec,$min,$hour,$day,$mon,$year,$wday) = localtime(time);
$year += 2000;
Of course, this will return 2100 (because localtime is
returning the current year minus 1900) - ahhh wrong answer.
So yes, there are no Y2K compliance issues with Perl. As with many other Y2K problems… it is not
the computer's fault… it's the programmers'.
