Preferred bug tracker

Please visit the preferred bug tracker to report your issue.

This queue is for tickets about the HTTP-Date CPAN distribution.

Report information
The Basics
Id:
12068
Status:
resolved
Priority:
Low/Low
Queue:

People
Owner:
Nobody in particular
Requestors:
steve.hay [...] uk.radan.com
Cc:
AdminCc:

BugTracker
Severity:
Important
Broken in:
(no value)
Fixed in:
(no value)



Subject: Test failure on Win32: t/base/date.t test 31
Relevant output from "perl -Mblib t/base/date.t" is: 'Mar 27 11:02' => 1111921320 (1111917720) not ok 31 This is running bleadperl (@24099) with libwww-perl-5.803 on WinXP. Built with VC++ 6.0. Times are different by 3600 seconds. Is this because I'm in the UK and we've just entered BST? Note that in the UK DST begins on last Sunday in March, whereas US rule is first Sunday in April. If I change my clock to Apr 30 then the test succeeds: 'Apr 27 11:06' => 1114596360 (1114596360) ok 31
What could LWP do about this? Seems like a misconfigured system to me.
[GAAS - Tue Dec 6 09:26:17 2005]:
Show quoted text
> What could LWP do about this? > Seems like a misconfigured system to me.
I don't know what LWP could do about it. That's why I filed a bug report rather than send a patch ;-) The system is not misconfigured any more than any other UK Windows systems are. I'm not sure if it is a Windows-specific problem or a UK-specific problem.
Let's see if we can get the following test program to fail: use Test::More tests => 2; use Time::Local qw(timelocal); my $t1 = 1111917720; my @t = localtime($t1); my $t2 = timelocal(@t); is($t1, $t2); is(localtime($t1), localtime($t2)); This should match how HTTP::Date would use timelocal() to convert the date string back to a time value. This succeeds for me. Can you try to run it on your computer?
Show quoted text
> Let's see if we can get the following test program to fail: > > use Test::More tests => 2; > use Time::Local qw(timelocal); > my $t1 = 1111917720; > my @t = localtime($t1); > my $t2 = timelocal(@t); > is($t1, $t2); > is(localtime($t1), localtime($t2));
This program fails for me on Windows XP when I change the time zone to something called "(GMT) Greenwich middeltid: Dublin, Edinburgh, Lisboa, London" and check the box that says something like "Adjust time automaticly for summer time" (translated from Norwegian). If I uncheck the summer time adjustment it does not fail. If I select the timezone "(GMT+01:00) Amsterdam, Berline, Bern, Oslo,..." it does not fail.
[GAAS - Tue Dec 6 13:59:01 2005]:
Show quoted text
> > Let's see if we can get the following test program to fail: > > > > use Test::More tests => 2; > > use Time::Local qw(timelocal); > > my $t1 = 1111917720; > > my @t = localtime($t1); > > my $t2 = timelocal(@t); > > is($t1, $t2); > > is(localtime($t1), localtime($t2));
> > This program fails for me on Windows XP when I change the > time zone to something called "(GMT) Greenwich middeltid: Dublin, > Edinburgh, Lisboa, London" and check the box that says something > like "Adjust time automaticly for summer time" (translated from > Norwegian). If I uncheck the summer time adjustment it does not > fail. If I select the timezone "(GMT+01:00) Amsterdam, Berline, Bern, > Oslo,..." it does not fail.
Yes, it fails for me too. My system is in the same time zone that you used above ("(GMT) Greenwich Mean Time : Dublin, Edinburgh, Libson, London") and also has "Automatically adjust clock for daylight saving changes" set. This is the default configuration in the UK. As you found too, switching off that setting or changing to Amsterdam time makes the test program succeed. It also fails with $t1 = 1111967999 but succeeds with $t1 = 1111968000.
[SHAY - Wed Dec 7 04:13:12 2005]:
Show quoted text
> > It also fails with $t1 = 1111967999 but succeeds with $t1 = > 1111968000.
I also meant to say it succeeds with $t1 = 1111885199 but fails with $t1 = 1111885200. So it fails in the range 1111885200 <= $t1 <= 1111967999. This is something like the whole of Sun Mar 27 2005. I had wondered if this was something to do with the UK summer time rule being different from the US rule (UK changes on last Sunday in March, US changes on first Sunday in April), but it that were the problem then I'd expect the test to fail for the entire week between those two Sundays, not just on the last Sunday in March. So now I'm even more confused.
[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.


This service runs on Request Tracker, is sponsored by The Perl Foundation, and maintained by Best Practical Solutions.

Please report any issues with rt.cpan.org to rt-cpan-admin@bestpractical.com.