On Fri, May 13, 2005 at 04:40:56PM -0400, John Peacock wrote: > >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.
Let's be civil and sane here and not a bunch of old Unix farts. This is not about stupid users, its about not expecting new Perl users to know details of Unix esoteria that Perl is supposed to (and usually does) hide. Here's a simple scenario where a user is surprised by localtime's behavior that doesn't involve them bashing at the keyboard with a club. You have dates stored as unix time with math done in unix time. One of those dates is Jan 2, 1970. You subtract 3 days (60 * 60 * 24 * 3) from that. Suddenly localtime() is returning weird dates with no indication as to why. To add additional confusion, on some systems localtime(-1) will work. On some it will not. > >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. ;-) Parrot is likely to have to do the same thing Perl 5 would: have its own internal datetime handling library. Perhaps we should take a peek at what the Parrot folks are doing. > >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]). Agreeing that its a good idea is orthoganal to its implementation difficulty. The nice thing about Open Source is some Random Genius can come along and surprise us with an implementation of something we consider to be very difficult. From what I can scrape out of the above, you'd be ok if someone dropped in a patch for native Perl date handling, however it happens to work. What about #2: the warning that you've overflowed the native localtime()? > 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. I don't think I understand how this is relevant or where Y2K comes in. I probably just don't understand the TAI issue. -- Michael G Schwern [EMAIL PROTECTED] http://www.pobox.com/~schwern 'All anyone gets in a mirror is themselves,' she said. 'But what you gets in a good gumbo is everything.' -- "Witches Abroad" by Terry Prachett
