Re: [MacPerl] unsigned longs (68K CPU)

[schinder@pjstoaster.pg.md.us (Paul Schinder)]

 Diller Ryan <dryan@slonet.org> writes:
} I seem  to recall a discussion about this in the past, but I can't find any
} traces.  An old  problem has returned.   It is the conflict between signed
} long integers and the 'Time::Local' package,  at least on the 68K CPU.
} 
} Long integers in MacPerl 5.1.0 r2b2 are compared as signed numbers,  in
} 5.0.7 they were unsigned.  In combination with the use of the Macintosh
} epoch (1904), this messes up the 'time' modules because they use a negative
} number as an error indicator.  Macintosh epoch time values exceeded 2**31
} in early 1972.
} 
} The different behavior between MacPerl 5.0.7 and 5.1.0b2r2 can be shown with:
} 
}       use Time::Local;
}       $i = 2**31-1;  $j = $i++;
}       print "Sign change: $i  $j\n";
} 
}       print "Date problem: ";
}       print timegm(0,0,0, 1,0,72), "  ", timegm(0,0,0, 1,1,72), "\n";
} 
} Is there an update or non-conflicting work-around?  Changing the library
} code is an immediate fix, but I worry about future repercussions.

I run your script and get:

Sign change: -2147483648  2147483647
Date problem: 2145902400  2148580800

But I'm using a modified Time::Local, in which I've forced a comparison
to be done as floating point rather than integer, because the integer
compare exercises a bug in Perl 5.002/3 (which has reportedly been
fixed in the latest development vesion of Perl) .The fixed library
routine (one of three that I've had to fix so far) is in <ftp://mors.gsfc.nasa.gov/pub/MacPerl/Scripts/Beta/Fixed_Library_Routines/>.

} 
} Diller
} 
} 
} 
} 
---
--------
Paul J. Schinder
NASA Goddard Space Flight Center,
Code 693, Greenbelt, MD 20771 USA
schinder@pjstoaster.pg.md.us