Inspired by a recent Slashdot post (oh, the irony :-) ), I see that we're coming up to a major rollover for the UNIX 32-bit clock on Sept 9, 2001, in which we go from 999999999 to 1000000000. While this shouldn't be serious problem as much as the Y2K bug, there is potental for problems if you have used the string comparision functions for comparing dates:
use strict;
my $b1 = 900000000;
my $b2 = 999999999;
my $a = 1000000001;
print (( $b1 < $b2 ) ? "True\n" : "False\n");
print (( $b1 < $a ) ? "True\n" : "False\n");
print (( $b1 lt $b2 ) ? "True\n" : "False\n");
print (( $b1 lt $a ) ? "True\n" : "False\n");
The output of this code (on Perl 5.005, NT) is:
True
True
True
False
Which, of course, is obvious for string comparisons. Now, while we all know as good little programmers to avoid using string comparisons when we are comparing numbers, we also know to use more than 2 digits for the year when given plenty of resources. It might be wise to take a look at any mission-critical code and verify that if you are comparing dates that you are doing it numerically. Or even better, consider switching to modules like
Date::Manip or
Date::Calc that will avoid this type of problem.
Dr. Michael K. Neylon - mneylon-pm@masemware.com
||
"You've left the lens cap of your mind on again, Pinky" - The Brain