[SHAY - Wed Dec 7 04:35:02 2005]:
Show quoted text>
> So it fails in the range 1111885200 <= $t1 <= 1111967999. This is
> something like the whole of Sun Mar 27 2005.
Is the following C test program the same thing?
#include <stdio.h>
#include <time.h>
void main(void) {
time_t t1, t2;
struct tm *t;
t1 = 1111917720;
t = localtime(&t1);
t2 = mktime(t);
printf("t1 = %lu, %s", t1, ctime(&t1));
printf("t2 = %lu, %s", t2, ctime(&t2));
}
If so then it looks more like a Perl / Time::Local problem than a
Windows problem because the above program works fine on the same UK
Windows system (with summer time adjustment set) that the Perl program
fails on. Output is:
t1 = 1111917720, Sun Mar 27 11:02:00 2005
t2 = 1111917720, Sun Mar 27 11:02:00 2005
Printing out the tm_isdst member of *t shows that it is set to 1. The
Perl program also has this flag set ($t[8] == 1).
In fact, all nine members of *t are identical to all nine members of @t
in the Perl program, so we have a case of Perl's
Time::Local::timelocal() behaving differently to C's mktime() when both
are given the same input.
[Pause to look at docs...]
Oh, hang on. timelocal() doesn't actually take nine arguments. It only
takes the first six, so it doesn't get passed the "isdst" flag.
Simply using POSIX::mktime() instead of Time::Local::timelocal() fixes
the test program.
So it looks like a bug in timelocal(), especially given that its docs
say that it is "always guaranteed to agree with localtime()".
Why doesn't timelocal() take all nine of the arguments that localtime()
returned? Why isn't it just a wrapper to mktime() anyway? And the
timelocal() docs don't even mention POSIX::mktime()!
Anyway, can LWP be changed to use POSIX::mktime() instead of
Time::Local::timelocal()? I could then close this bug and file a new
one under Time::Local instead.
