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");

[download]
The output of this code (on Perl 5.005, NT) is: 
True
True
True
False

[download]
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

Replies are listed 'Best First'.
Re: The Y2.001775K Bug
by repson (Chaplain) on Apr 19, 2001 at 07:51 UTC
    Thought I'd just point out that this has been present on merlyn's homepage for a while, including the current countdown of 20 weeks and 2 days, titled 'the countdown to U1e9' and right next to the Y3K countdown.
[reply]
Re: The Y2.001775K Bug
by Cybercosis (Monk) on Apr 19, 2001 at 06:32 UTC
    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.

    Not to sound rude, but this is incorrect. At the stated date, the UNIX clock will read 987654321. The "big" rollover doesn't occur until 2038.

    ~Cybercosis

[reply]
      This "rollover," while still within the 32-bit signed space of a time_t, will indeed happen on 09.09.2001 ... 987654321 is scheduled to hit tomorrow sometime (today at 23:25:21 CDT)

      --
      Me spell chucker work grate. Need grandma chicken.

[reply]
[d/l]
      masem didn't actually mean a rollover - I think he was just using it as an analogy He meant "we're coming up to a point where all the nines go to zeros and we put a one in front".

      I'm not quite sure what he means by check your string comparisons, because I can't see a way that it could change the outcome of a string comparison unless you were doing something terribly foolish like 

      if (substr($this_dat,0,4) eq substr($that_date,0,4) {

      [download]

      In which case it would come up false when you clearly would have wanted it to be true.

      It was an interesting snippet anyway, just like yakko's below.

      ____________________
      Jeremy
      I didn't believe in evil until I ate it.

[reply]
[d/l]
        Here's a possible way that you can run into this blunder, a good possible 'newbish' problem. 
        # Generate files...
my $time = time();
open FILE ">$time.txt" or die $!;
print FILE  $stuff;
close FILE;
# this is repeated often, as from CGI...
#
# Retrieval now...
my @files = get_list_of_files();
@files = sort { $a cmb $b } @files;
foreach my $file ( @files ) {
   do_something_with_file ( $file );
}

        [download]
        If the files are created across the 9/9/01 boundary, you are going to missort these later.

        Oddly enough, I use this exact technique in my recent code snippet, notepad.pl; however, I do protect from this by sprintf'ing the time into a much much longer string that should be ok until 64-bit systems...without that sprintf, that code suffers from the same problem.

        }

        Dr. Michael K. Neylon - mneylon-pm@masemware.com || "You've left the lens cap of your mind on again, Pinky" - The Brain
[reply]
[d/l]

Back to Meditations