Skip Menu |

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

Report information
The Basics
Id: 54779
Status: resolved
Priority: 0/
Queue: Date-Manip

People
Owner: Nobody in particular
Requestors: chrisb [...] debian.org
Cc:
AdminCc:

Bug Information
Severity: Important
Broken in: 6.07
Fixed in: (no value)



Subject: Date_ConvTZ doesn't seem to cope with mixed timezone formats correctly
The Date_ConvTZ function in the new version of Date::Manip doesn't seem to cope with mixed timezone formats (eg: mixing +nnnn and timezone abbreviations) when dealing with DST. The attached script demonstrates the problem. With Date::Manip 6.07, this outputs: +0000 => BST 2001012823:05:00 2001082823:05:00 GMT => +0000 2001012823:05:00 2001082900:05:00 GMT => BST 2001012823:05:00 2001082900:05:00 GMT => Europe/London 2001012823:05:00 2001082900:05:00 As you can see, this version of Date::Manip considers +0000 and BST to always be the same, whereas converting GMT to +0000 adds an hour during DST. I'd expect it to ALWAYS add an hour from +0000 => BST, and NEVER add an hour from GMT => +0000. Likewise, GMT => BST should always add an hour, no matter what the date is. The timezone abbreviations GMT and BST should always refer to +0000 and +0100, the definition of these abbreviations is not affected by DST. On the other hand, GMT => London is to be correct (the definition of Europe/London should change with DST). For comparison, Date::Manip 5.54 outputs the following: +0000 => BST 2001012900:05:00 2001082900:05:00 GMT => +0000 2001012823:05:00 2001082823:05:00 GMT => BST 2001012900:05:00 2001082900:05:00 GMT => Europe/London 2001012823:05:00 2001082823:05:00
Subject: test.pl
#!/usr/bin/perl use Date::Manip; #Date_Init("SetDate=now,+0000"); Date_Init("TZ=+0000"); print "+0000 => BST\n"; print Date_ConvTZ("2001012823:05:00", "+0000", "BST")."\n"; print Date_ConvTZ("2001082823:05:00", "+0000", "BST")."\n"; print "\nGMT => +0000\n"; print Date_ConvTZ("2001012823:05:00", "GMT", "+0000")."\n"; print Date_ConvTZ("2001082823:05:00", "GMT", "+0000")."\n"; print "\nGMT => BST\n"; print Date_ConvTZ("2001012823:05:00", "GMT", "BST")."\n"; print Date_ConvTZ("2001082823:05:00", "GMT", "BST")."\n"; print "\nGMT => Europe/London\n"; print Date_ConvTZ("2001012823:05:00", "GMT", "Europe/London")."\n"; print Date_ConvTZ("2001082823:05:00", "GMT", "Europe/London")."\n";
You uncovered an interesting "feature" of how Date::Manip determined timezones when working with offsets. Date::Manip always needs to find out what timezone you're working with, and by default, it would test standard times followed by daylight saving time zones. So an offset of +0000 would always get treated as a standard time (since there are any number of standard timezones that have an offset of +0000 through the entire year. I've corrected this so that if the date is available (as it is with the Date_ConvTZ routine), it'll test daylight savings time zones first when the timezone is specified as an offset. This will give the desired behavior almost all of the time (though I've noted in the manual that dates close to a time change may behave unexpectedly... the best solution to that is to not use offsets) This will be in the next release, however, it still doesn't give what you state you expect. You say that +0000 => BST whould always add an hour, but that's not the case. The BST abbreviation is not a timezone of course. It is an abbreviation which refers (by default) to the Europe/London timezone. The Europe/Londone timezone is at an offset of +0000 on 2001-01-28 and at +0100 at 2001-08-28. So converting the 2001-01-28 date should NOT add an hour (since the offset is +0000). The 2001-08-28 date should add an hour. You say that "BST" should always refer to an offset of +0100, but during January, there is no timezone in the world that uses the abbreviation BST and has an offset of +0100, so I disagree with your statement. Similar for the GMT => BST, and GMT = Europe/London tests (they're all different ways of saying the same thing in this case). The Date::Manip 5.xx output is (as expected) wrong since it doesn't handle timezones well at all. Anyway, look for this to be corrected in 6.08.
Show quoted text
> This will give the desired > behavior almost all of the time (though I've noted in the manual that > dates close to a time change may behave unexpectedly... the best > solution to that is to not use offsets)
I retract this part of my answer. I believe that using offsets in Date_ConvTZ should work correctly all of the time, so there is no reason not to use them if conveniant.
From: chrisb [...] debian.org
Sorry to bring this up again, but I still believe there is a problem. Ignoring the stuff about BST, there are still issues with the handling of GMT. The following script: #!/usr/bin/perl use Date::Manip; Date_Init('TZ=GMT'); print Date_ConvTZ('2002101008:55:00','GMT','+0100')."\n"; print Date_ConvTZ('2002111008:55:00','GMT','+0100')."\n"; produces the output: 2002101010:55:00 2002111009:55:00 So during DST, converting from GMT to +0100 is adding 2 hours. However, this is wrong. The offset +0100 means "GMT plus 1 hour". That is the definition of an "offset", or to give it its full name: "offset from GMT". GMT is, by definition +0000 ALL YEAR ROUND. It does NOT change during daylight savings time. It is NOT the same as Europe/London. The website for GMT (yes, there is one) agrees with me: http://wwp.greenwichmeantime.com/what-is-gmt.htm
From: chrisb [...] debian.org
Still having problems with this, but I noticed that using the string "etc/gmt+N" works where "+0N00" doesn't: (sid)chrisb@cob:~/src/xmltv-cvs/t/data$ cat bug2.pl #!/usr/bin/perl use Date::Manip; Date_Init('TZ=GMT'); print Date_ConvTZ('2002101008:55:00','GMT','etc/gmt+1')."\n"; print Date_ConvTZ('2002111008:55:00','GMT','etc/gmt+1')."\n"; (sid)chrisb@cob:~/src/xmltv-cvs/t/data$ perl bug2.pl 2002101009:55:00 2002111009:55:00 This is correct. compared to: On Wed Mar 10 05:31:33 2010, crispygoth wrote: Show quoted text
> #!/usr/bin/perl > > use Date::Manip; > > Date_Init('TZ=GMT'); > print Date_ConvTZ('2002101008:55:00','GMT','+0100')."\n"; > print Date_ConvTZ('2002111008:55:00','GMT','+0100')."\n"; > > produces the output: > > 2002101010:55:00 > 2002111009:55:00
This is now fixed and will be in the next release.