for why this is a problem. Perl could work around it by using a different time value (e.g. 64bit TAI), but it would require custom code.
A) This assumes new Perl programmers already have knowledge of C or similar
language as well as the details of their operating system. This is no longer true.
Anyone feeding random numbers into localtime shouldn't be considered a "new Perl programmer" anymore.
B) There's nothing that says because C made this mistake that Perl should, too. In fact, everything would suggest Perl would correct this arbitrary limitation in the same way as we've corrected other common C limitations such as fixed size strings, arrays and numbers which transparently morph from integers to floats to doubles...
Yeah, in Perl 6. That's down the hall. ;-)
1) Document that there is a system dependent limitation perlfunc and perlport and to only trust localtime(), and any date handling code derived from localtime(), to work from 1970 to 2038. It may work for more but that cannot be trusted.
This gets my vote as the only realistic solution for Perl5. Although we /could/ produce a portable 64bit time library, it isn't that simple to handle the conversion from TAI (or whatever) to human dates (see the DateTime project for more details than you could possibly want to know[1]).
John
1. I like this page:
http://developer.apple.com/technotes/tn/tn1049.html
which correctly points out that the Mac never had a Y2K problem without mentioning the fact that the Mac epoch (12:00:00 a.m., January 1, 1904) is a floating epoch (i.e. not tied to GMT), so it is completely worthless for performing date calculations that cross DST, for example.
-- John Peacock Director of Information Research and Technology Rowman & Littlefield Publishing Group 4501 Forbes Boulevard Suite H Lanham, MD 20706 301-459-3366 x.5010 fax 301-429-5748
