Bug #52849 for DateTime-TimeZone-Tzfile: DateTime::TimeZone gives different is

Wed Dec 16 20:19:29 2009 mschwern [...] cpan.org - Ticket created

Subject:

DateTime::TimeZone gives different is_dst from Tzfile

Attached is a test demonstrating that Tzfile gives a different value for is_dst() than DateTime::TimeZone for a date in the far future. Extrapolating the current daylight savings time rules forward, Aug 8th, 3000 in America/Chicago should be DST if I'm not mistaken.

Subject:

test.plx

Download test.plx
application/octet-stream 580b

Message body not shown because it is not plain text.

Thu Dec 17 04:58:33 2009 zefram [...] fysh.org - Correspondence added

Subject:	Re: [rt.cpan.org #52849] DateTime::TimeZone gives different is_dst from Tzfile
Date:	Thu, 17 Dec 2009 09:58:12 +0000
To:	Michael G Schwern via RT <bug-DateTime-TimeZone-Tzfile [...] rt.cpan.org>
From:	Zefram <zefram [...] fysh.org>

Michael G Schwern via RT wrote: Show quoted text

>Attached is a test demonstrating that Tzfile gives a different value for >is_dst() than DateTime::TimeZone for a date in the far future.

Please send me a copy of your /usr/share/zoneinfo/America/Chicago file. Much depends on the details of what's in it. -zefram

Thu Dec 17 04:58:34 2009 The RT System itself - Status changed from 'new' to 'open'

Thu Dec 17 06:21:22 2009 schwern [...] pobox.com - Correspondence added

Subject:	Re: [rt.cpan.org #52849] DateTime::TimeZone gives different is_dst from Tzfile
Date:	Thu, 17 Dec 2009 03:21:03 -0800
To:	bug-DateTime-TimeZone-Tzfile [...] rt.cpan.org
From:	Michael G Schwern <schwern [...] pobox.com>

Zefram via RT wrote: Show quoted text

> <URL: http://rt.cpan.org/Ticket/Display.html?id=52849 > > > Michael G Schwern via RT wrote:

>> Attached is a test demonstrating that Tzfile gives a different value for >> is_dst() than DateTime::TimeZone for a date in the far future.

> > Please send me a copy of your /usr/share/zoneinfo/America/Chicago file. > Much depends on the details of what's in it.

Attached. Its from OS X 10.6.2. -- 54. "Napalm sticks to kids" is *not* a motivational phrase. -- The 213 Things Skippy Is No Longer Allowed To Do In The U.S. Army http://skippyslist.com/list/

Download Chicago
application/octet-stream 1.2k

Message body not shown because it is not plain text.

Thu Dec 17 06:46:49 2009 zefram [...] fysh.org - Correspondence added

Subject:	Re: [rt.cpan.org #52849] DateTime::TimeZone gives different is_dst from Tzfile
Date:	Thu, 17 Dec 2009 11:45:00 +0000
To:	Michael G Schwern via RT <bug-DateTime-TimeZone-Tzfile [...] rt.cpan.org>
From:	Zefram <zefram [...] fysh.org>

Michael G Schwern via RT wrote: Show quoted text

>Attached. Its from OS X 10.6.2.

It's a version-1 tzfile. This format has no facility to give a rule for DST changes beyond those explicitly listed, and its times are limited to 32 bits so it can't represent any changes beyond 2038. It is arguable that DT:TZ:Tzfile should have refused to give any offset for the year 3000, but that behaviour would screw up interpretation of some other perfectly good version-1 tzfiles. Generally the tzfile format is not very clear about edge behaviour. I'm intending to review DT:TZ:Tzfile's handling of edge cases, btw. In a version-2 tzfile, times are 64-bit, and future dates can be covered by a rule expressed in System V $TZ format (as I just described on the datetime list). Attached is the v2 America/Chicago from my Debian machine, where your test script produces correct output (is_dst=1 in both cases). So, basically, not a bug. As I suggested on the datetime list, a Perl module to provide access to current tzfiles would be nice, as something to combine with DT:TZ:Tzfile. -zefram

Download v2_America_Chicago
application/octet-stream 3.4k

Message body not shown because it is not plain text.

Thu Dec 17 16:16:35 2009 schwern [...] pobox.com - Correspondence added

Subject:	Re: [rt.cpan.org #52849] DateTime::TimeZone gives different is_dst from Tzfile
Date:	Thu, 17 Dec 2009 13:16:14 -0800
To:	bug-DateTime-TimeZone-Tzfile [...] rt.cpan.org
From:	Michael G Schwern <schwern [...] pobox.com>

Zefram via RT wrote: Show quoted text

> It's a version-1 tzfile. This format has no facility to give a rule for > DST changes beyond those explicitly listed, and its times are limited to > 32 bits so it can't represent any changes beyond 2038. It is arguable > that DT:TZ:Tzfile should have refused to give any offset for the year > 3000, but that behaviour would screw up interpretation of some other > perfectly good version-1 tzfiles. Generally the tzfile format is not > very clear about edge behaviour. I'm intending to review DT:TZ:Tzfile's > handling of edge cases, btw.

If its technically possible, I'd just extend the current rules forward. Its not like a 64 bit file is going to really know the future rules anyway, and that's realistically the best you can do. -- Ahh email, my old friend. Do you know that revenge is a dish that is best served cold? And it is very cold on the Internet!

Thu Dec 17 16:23:06 2009 zefram [...] fysh.org - Correspondence added

Subject:	Re: [rt.cpan.org #52849] DateTime::TimeZone gives different is_dst from Tzfile
Date:	Thu, 17 Dec 2009 21:22:45 +0000
To:	Michael G Schwern via RT <bug-DateTime-TimeZone-Tzfile [...] rt.cpan.org>
From:	Zefram <zefram [...] fysh.org>

Michael G Schwern via RT wrote: Show quoted text

>If its technically possible, I'd just extend the current rules forward.

That's not possible for version-1 tzfiles, where the rule is not encoded at all. Version-2 tzfiles explicitly encode the rule to use for the future, and DT:TZ:Tzfile makes proper use of that. Obviously, if I start distributing binary tzfiles as a CPAN package, I'll make sure they're all version 2. -zefram

Thu Dec 17 16:59:50 2009 schwern [...] pobox.com - Correspondence added

Subject:	Re: [rt.cpan.org #52849] DateTime::TimeZone gives different is_dst from Tzfile
Date:	Thu, 17 Dec 2009 13:59:32 -0800
To:	bug-DateTime-TimeZone-Tzfile [...] rt.cpan.org
From:	Michael G Schwern <schwern [...] pobox.com>

Zefram via RT wrote: Show quoted text

> That's not possible for version-1 tzfiles, where the rule is not encoded > at all. Version-2 tzfiles explicitly encode the rule to use for the > future, and DT:TZ:Tzfile makes proper use of that. > > Obviously, if I start distributing binary tzfiles as a CPAN package, > I'll make sure they're all version 2.

Yeah, I guess this goes away for the general case if its using those default v2 files. -- Ahh email, my old friend. Do you know that revenge is a dish that is best served cold? And it is very cold on the Internet!

Thu Dec 17 17:17:45 2009 schwern [...] pobox.com - Correspondence added

Subject:	Re: [rt.cpan.org #52849] DateTime::TimeZone gives different is_dst from Tzfile
Date:	Thu, 17 Dec 2009 13:59:32 -0800
To:	bug-DateTime-TimeZone-Tzfile [...] rt.cpan.org
From:	Michael G Schwern <schwern [...] pobox.com>

Zefram via RT wrote: Show quoted text

> That's not possible for version-1 tzfiles, where the rule is not encoded > at all. Version-2 tzfiles explicitly encode the rule to use for the > future, and DT:TZ:Tzfile makes proper use of that. > > Obviously, if I start distributing binary tzfiles as a CPAN package, > I'll make sure they're all version 2.

Yeah, I guess this goes away for the general case if its using those default v2 files. -- Ahh email, my old friend. Do you know that revenge is a dish that is best served cold? And it is very cold on the Internet!

Thu Dec 17 17:22:45 2009 ZEFRAM [...] cpan.org - Status changed from 'open' to 'resolved'

Bug #52849 for DateTime-TimeZone-Tzfile: DateTime::TimeZone gives different is_dst from Tzfile