Skip Menu |

Preferred bug tracker

Please visit the preferred bug tracker to report your issue.

This queue is for tickets about the DateTime-TimeZone CPAN distribution.

Report information
The Basics
Id: 118599
Status: rejected
Priority: 0/
Queue: DateTime-TimeZone

People
Owner: Nobody in particular
Requestors: ROBN [...] cpan.org
Cc:
AdminCc:

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



Subject: Pacific/Tongatapu tests fail with tzdata 2016i.
DateTime-TimeZone 2.06 with tzdata 2016i on Perl 5.20.2 produces the following error in tests: t/zd_Pacific-Tongatapu.t ............... 1/17550 # Failed test 'local hour should be 17 (2038-01-19 17:14:06)' # at t/zd_Pacific-Tongatapu.t line 1853. # got: '16' # expected: '17' # Failed test 'is_dst should be 1 (2038-01-19 17:14:06)' # at t/zd_Pacific-Tongatapu.t line 1857. # got: '0' # expected: '1' # Failed test 'offset should be 50400 (2038-01-19 17:14:06)' # at t/zd_Pacific-Tongatapu.t line 1858. # got: '46800' # expected: '50400' # Failed test 'short name should be +14 (2038-01-19 17:14:06)' # at t/zd_Pacific-Tongatapu.t line 1859. # got: '+13' # expected: '+14' t/zd_Pacific-Tongatapu.t ............... 17182/17550 # Looks like you failed 4 tests of 17550. t/zd_Pacific-Tongatapu.t ............... Dubious, test returned 4 (wstat 1024, 0x400) Failed 4/17550 subtests
You can't regenerate the tests without also regenerating the zones and expect anything to pass. I just did both and all the tests passed. A new release will be out shortly. Cheers, -dave
On Wed Nov 02 23:05:11 2016, DROLSKY wrote: Show quoted text
> You can't regenerate the tests without also regenerating the zones and > expect anything to pass.
I followed my normal process for when a tz update comes out: run tools/update-from-latest-olson, then build the package. The tests always pass, which is why I opened a ticket this time. So is that not the right process?
On 2016-11-02 22:10:01, ROBN wrote: Show quoted text
> On Wed Nov 02 23:05:11 2016, DROLSKY wrote:
> > You can't regenerate the tests without also regenerating the zones > > and > > expect anything to pass.
> > I followed my normal process for when a tz update comes out: run > tools/update-from-latest-olson, then build the package. The tests > always pass, which is why I opened a ticket this time. So is that not > the right process?
No, that's right. But I ran the same script and it worked for me. I'm guessing that the script didn't actually regenerate your tz database files into the right location, so that maybe zdump didn't produce output based on the new files. But that's just a guess. That script is not exactly battle tested for all systems. I've got it working for me, but I have no idea how well it works for anyone else, unfortunately. Maybe share the output of the script?
On Thu Nov 03 00:12:55 2016, DROLSKY wrote: Show quoted text
> That script is not exactly battle tested for all systems. I've got it > working for me, but I have no idea how well it works for anyone else, > unfortunately. > > Maybe share the output of the script?
Interesting. In our case, we have to run that script (modified to pass --old to tools/parse_olson) because we need the Etc/GMT-N zones, which is why I do this at all. I'll look into it further and let you know if I see anything interesting.
I see nothing interesting. Full output of update-from-latest-olson and the offending test here: https://gist.github.com/robn/fe47520e86e1c0bb6270ea635fc05f0a I have run this on stock Debian wheezy (Perl 5.14) and jessie (5.20) systems, same result. (Incidentally, the only reason I'm doing this is because I need the GMT zones (per PR#1) so I need to run parse_olson with --old).
The generated zone file is slightly different (vs the CPAN version): ---------- --- lib/DateTime/TimeZone/Pacific/Tongatapu.pm 2016-11-03 03:05:04.000000000 +0000 +++ /usr/src/datetime-timezone-build/DateTime-TimeZone-2.07/lib/DateTime/TimeZone/Pacific/Tongatapu.pm2016-11-07 22:33:35.053696907 +0000 @@ -3,7 +3,7 @@ # DateTime::TimeZone module distribution in the tools/ directory # -# Generated from /tmp/kLJgvD2F1Z/australasia. Olson data version 2016i +# Generated from /tmp/mV47OZJj0J/australasia. Olson data version 2016i # # Do not edit this file directly. # @@ -365,17 +365,6 @@ my $rules = [ bless( { - 'at' => '2:00', - 'from' => '2016', - 'in' => 'Nov', - 'letter' => 'S', - 'name' => 'Tonga', - 'offset_from_std' => 3600, - 'on' => 'Sun>=1', - 'save' => '1:00', - 'to' => 'max' - }, 'DateTime::TimeZone::OlsonDB::Rule' ), - bless( { 'at' => '3:00', 'from' => '2017', 'in' => 'Jan', @@ -385,6 +374,17 @@ 'on' => 'Sun>=15', 'save' => '0', 'to' => 'max' + }, 'DateTime::TimeZone::OlsonDB::Rule' ), + bless( { + 'at' => '2:00', + 'from' => '2016', + 'in' => 'Nov', + 'letter' => 'S', + 'name' => 'Tonga', + 'offset_from_std' => 3600, + 'on' => 'Sun>=1', + 'save' => '1:00', + 'to' => 'max' }, 'DateTime::TimeZone::OlsonDB::Rule' ) ] ; ---------- I wondered if it might be the ordering at fault, but reordering doesn't fix it. I've been looking at the actual test output, and I think perhaps the generated test is wrong? I'm very new at reading this, but: Rule Tonga 2016 max - Nov Sun>=1 2:00 1:00 S Rule Tonga 2017 max - Jan Sun>=15 3:00 0 - Does that mean a transition from DST->not-DST on the Sunday mid-Jan? In 2038 that would be the 17th, so these two tests on the 19th, one second apart, should actually both be non-DST? { my $dt = DateTime->new( year => 2038, month => 1, day => 19, hour => 3, minute => 14, second => 6, time_zone => 'UTC', ); $dt->set_time_zone( 'Pacific/Tongatapu' ); is( $dt->year, 2038, 'local year should be 2038 (2038-01-19 17:14:06)' ); is( $dt->month, 1, 'local month should be 1 (2038-01-19 17:14:06)' ); is( $dt->day, 19, 'local day should be 19 (2038-01-19 17:14:06)' ); is( $dt->hour, 17, 'local hour should be 17 (2038-01-19 17:14:06)' ); is( $dt->minute, 14, 'local minute should be 14 (2038-01-19 17:14:06)' ); is( $dt->second, 6, 'local second should be 6 (2038-01-19 17:14:06)' ); is( $dt->is_dst, 1, 'is_dst should be 1 (2038-01-19 17:14:06)' ); is( $dt->offset, 50400, 'offset should be 50400 (2038-01-19 17:14:06)' ); is( $dt->time_zone_short_name, '+14', 'short name should be +14 (2038-01-19 17:14:06)' ); } { my $dt = DateTime->new( year => 2038, month => 1, day => 19, hour => 3, minute => 14, second => 7, time_zone => 'UTC', ); $dt->set_time_zone( 'Pacific/Tongatapu' ); is( $dt->year, 2038, 'local year should be 2038 (2038-01-19 16:14:07)' ); is( $dt->month, 1, 'local month should be 1 (2038-01-19 16:14:07)' ); is( $dt->day, 19, 'local day should be 19 (2038-01-19 16:14:07)' ); is( $dt->hour, 16, 'local hour should be 16 (2038-01-19 16:14:07)' ); is( $dt->minute, 14, 'local minute should be 14 (2038-01-19 16:14:07)' ); is( $dt->second, 7, 'local second should be 7 (2038-01-19 16:14:07)' ); is( $dt->is_dst, 0, 'is_dst should be 0 (2038-01-19 16:14:07)' ); is( $dt->offset, 46800, 'offset should be 46800 (2038-01-19 16:14:07)' ); is( $dt->time_zone_short_name, '+13', 'short name should be +13 (2038-01-19 16:14:07)' ); } I'm still reading about how the tests are generated. I'll add more here if I find anything interesting.
I think If found it. Debian's stock zdump produces weird rules Pacific/Tongatapu in 2038: [robn@utility2 jessie DateTime-TimeZone-2.07]$ /usr/bin/zdump --version zdump (Debian GLIBC 2.19-18+deb8u6) 2.19 /usr/share/zoneinfo/Pacific/Tongatapu Tue Jan 19 03:14:06 2038 UT = Tue Jan 19 17:14:06 2038 +14 isdst=1 gmtoff=50400 /usr/share/zoneinfo/Pacific/Tongatapu Tue Jan 19 03:14:07 2038 UT = Tue Jan 19 16:14:07 2038 +13 isdst=0 gmtoff=46800 2038-01-19 03:14:07 UTC is the max value for a 32-bit timestamp, so I guess that's a bug in Debian's (glibc's) zdump. I don't see a bug report for them; I will file one. It looks like it might be related to https://bugs.launchpad.net/ubuntu/+source/glibc/+bug/1587128. These rules do not appear when I use zdump that comes with tzdata. If I hack update-from-latest-olson to pass a --zdump parameter for a zdump binary built from 2016i (with some symlinks to get it looking for the right zoneinfo paths), the tests pass. Soooo... Would you take a patch to use the zdump that gets built? Using that version would take some reworking, since currently the built files have already been deleted by the time tests_from_zdump runs, and it only knows to look in /usr/local/etc/zoneinfo anyway (though not blatting all over /usr/share/zoneinfo would be a nice improvement for update-from-latest-onson anyway).
On 2016-11-07 19:39:29, ROBN wrote: Show quoted text
> I think If found it. Debian's stock zdump produces weird rules > Pacific/Tongatapu in 2038: > > [robn@utility2 jessie DateTime-TimeZone-2.07]$ /usr/bin/zdump > --version > zdump (Debian GLIBC 2.19-18+deb8u6) 2.19 > > /usr/share/zoneinfo/Pacific/Tongatapu Tue Jan 19 03:14:06 2038 UT = > Tue Jan 19 17:14:06 2038 +14 isdst=1 gmtoff=50400 > /usr/share/zoneinfo/Pacific/Tongatapu Tue Jan 19 03:14:07 2038 UT = > Tue Jan 19 16:14:07 2038 +13 isdst=0 gmtoff=46800 > > 2038-01-19 03:14:07 UTC is the max value for a 32-bit timestamp, so I > guess that's a bug in Debian's (glibc's) zdump. I don't see a bug > report for them; I will file one. It looks like it might be related to > https://bugs.launchpad.net/ubuntu/+source/glibc/+bug/1587128. > > These rules do not appear when I use zdump that comes with tzdata. If > I hack update-from-latest-olson to pass a --zdump parameter for a > zdump binary built from 2016i (with some symlinks to get it looking > for the right zoneinfo paths), the tests pass. > > Soooo... Would you take a patch to use the zdump that gets built? > Using that version would take some reworking, since currently the > built files have already been deleted by the time tests_from_zdump > runs, and it only knows to look in /usr/local/etc/zoneinfo anyway > (though not blatting all over /usr/share/zoneinfo would be a nice > improvement for update-from-latest-onson anyway).
Is this a 32- or 64-bit system? It seems _really_ weird to supply a zdump that only works with a 32-bit time_t on a 64-bit system. However, if you are a on a 32-bit system then this is working as expected. Did you test that the newly compiled zdump actually works differently? So A) the test generator should be fixed to ignore weird output on a 32-bit system; or B) Debian should be fixed. I think doing A is better than using the compiled zdump, since this could be an actual problem on a 32-bit system (I'm assuming there are still some in use out there).
No. This is a stock Debian 8 amd64 system (I installed one from scratch just to make sure). It produces output after 2038; it just seems to struggle when there's a transition "around" 2038. Compare the Debian version: [robn@utility2 jessie tzdb-2016i]$ /usr/bin/zdump -v -c 2037,2039 Pacific/Tongatapu Pacific/Tongatapu -9223372036854775808 = NULL Pacific/Tongatapu -9223372036854689408 = NULL Pacific/Tongatapu Sat Jan 17 12:59:59 2037 UT = Sun Jan 18 02:59:59 2037 +14 isdst=1 gmtoff=50400 /usr/bin/zdump: warning: zone "Pacific/Tongatapu" abbreviation "+14" lacks alphabetic at start Pacific/Tongatapu Sat Jan 17 13:00:00 2037 UT = Sun Jan 18 02:00:00 2037 +13 isdst=0 gmtoff=46800 Pacific/Tongatapu Sat Oct 31 12:59:59 2037 UT = Sun Nov 1 01:59:59 2037 +13 isdst=0 gmtoff=46800 Pacific/Tongatapu Sat Oct 31 13:00:00 2037 UT = Sun Nov 1 03:00:00 2037 +14 isdst=1 gmtoff=50400 Pacific/Tongatapu Tue Jan 19 03:14:06 2038 UT = Tue Jan 19 17:14:06 2038 +14 isdst=1 gmtoff=50400 Pacific/Tongatapu Tue Jan 19 03:14:07 2038 UT = Tue Jan 19 16:14:07 2038 +13 isdst=0 gmtoff=46800 Pacific/Tongatapu Sat Nov 6 12:59:59 2038 UT = Sun Nov 7 01:59:59 2038 +13 isdst=0 gmtoff=46800 Pacific/Tongatapu Sat Nov 6 13:00:00 2038 UT = Sun Nov 7 03:00:00 2038 +14 isdst=1 gmtoff=50400 Pacific/Tongatapu 9223372036854689407 = NULL Pacific/Tongatapu 9223372036854775807 = NULL vs 2016i: [robn@utility2 jessie tzdb-2016i]$ ./zdump -v -c 2037,2039 Pacific/Tongatapu Pacific/Tongatapu -9223372036854775808 = NULL Pacific/Tongatapu -9223372036854689408 = NULL Pacific/Tongatapu Sat Jan 17 12:59:59 2037 UT = Sun Jan 18 02:59:59 2037 +14 isdst=1 gmtoff=50400 Pacific/Tongatapu Sat Jan 17 13:00:00 2037 UT = Sun Jan 18 02:00:00 2037 +13 isdst=0 gmtoff=46800 Pacific/Tongatapu Sat Oct 31 12:59:59 2037 UT = Sun Nov 1 01:59:59 2037 +13 isdst=0 gmtoff=46800 Pacific/Tongatapu Sat Oct 31 13:00:00 2037 UT = Sun Nov 1 03:00:00 2037 +14 isdst=1 gmtoff=50400 Pacific/Tongatapu 9223372036854689407 = NULL Pacific/Tongatapu 9223372036854775807 = NULL I'm fairly certain this is a bug in the system zdump. If you've got a bright idea for working around it, that's fine, but using the one bundled with tzdata seems like a reasonable choice too, and as I said, it doesn't seem like a bad idea to change things to not trample the system-provided zoneinfo as well. FYI, this is the patch I'm currently testing: https://github.com/fastmailops/DateTime-TimeZone/commit/bd24f873bcc75ac263bf6ef611304b5743e36e71. I'm not 100% sure its right yet (there's some other changes I need to make to handle a non-CPAN build in my environment). It did manage to produce a working package with Etc/* zones for macOS though, which the current release version can't do.