: For ActivePerl 5.8.0 (806) this hasn't got anything to do with drives
: (volumes). It's just that on Windows (at least on my 2k box) localtime()
: doesn't take a negative argument.
That's interesting. In testing, when called with a negative argument
it returns epoch when run from the C: drive (or the drive where Perl
is installed), and nothing on the D: drive. I know you say that
drives don't have anything to do with it but this behaviour seems
odd. Is it just an inconsistency that shouldn't be relied upon?
So, has the following (intentionally terse) patch your approval :
--- pod/perlport.pod (revision 1200)
+++ pod/perlport.pod (working copy)
@@ -600,6 +600,8 @@
some large number. C<$offset> can then be added to a Unix time value
to get what should be the proper value on any system.
+On Windows, you shouldn't pass a negative value to C<gmtime> or C<localtime>.
=head2 Character sets and character encoding
Assume very little about character sets.
I think somebody said that even on POSIX systems a negative value does
not have be interpreted "correctly".
: This is from MinGW/include/time.h (GCC for Windows):
: * NOTE: localtime, and perhaps the others of the four functions grouped
: * below may return NULL if their argument is not 'acceptable'. Also note
: * that calling asctime with a NULL pointer will produce an Invalid Page
: * Fault and crap out your program. Guess how I know. Hint: stat called on
: * a directory gives 'invalid' times in st_atime etc...
: apparently a negative argument is not 'acceptable'