test failure #10

Closed
wwood opened this Issue May 22, 2016 · 8 comments

Comments

Projects
None yet
2 participants
@wwood

wwood commented May 22, 2016

Hi, I'm attempting to package tzinfo-data for Guix, and ran into this test failure. Any ideas?

  1) Failure:
TCDefinitions#test_all [/tmp/nix-build-ruby-tzinfo-data-1.2016.4.drv-0/tzinfo-data-1.2016.4/test/tc_definitions.rb:55]:
Local times don't match:
zdump:         Africa/Casablanca 2037-10-25T01:59:59+00:00 UTC 2037-10-25T02:59:59+00:00 WEST is_dst=1
tzinfo (u->l): Africa/Casablanca 2037-10-25T01:59:59+00:00 UTC 2037-10-25T01:59:59+00:00 WET is_dst=0.
--- expected
+++ actual
@@ -1 +1 @@
-#<DateTime: 2037-10-25T02:59:59+00:00 ((2465357j,10799s,0n),+0s,2299161j)>
+#<DateTime: 2037-10-25T01:59:59+00:00 ((2465357j,7199s,0n),+0s,2299161j)>


10 runs, 153467 assertions, 1 failures, 0 errors, 0 skips

Thanks.

@philr philr added the question label May 22, 2016

@philr

This comment has been minimized.

Show comment
Hide comment
@philr

philr May 22, 2016

Member

The test is failing at around the point when times can no longer be represented as 32-bit signed integers (the transition following the one that is failing is greater than 2^32 - 1).

The tzinfo-data tests rely on the zic and zdump tools from the IANA Time Zone Database. The failure therefore probably means that you have old versions of these tools that only support 32-bit times (I think MacOS X still ships with ancient 32-bit only versions).

I'd suggest compiling the latest version of the Time Zone Code package from the IANA Time Zone Database (currently tzcode2016d.tar.gz). Check the included README for build instructions. This will give you up to date versions of zic and zdump, which you'll need to add to your PATH ahead of the system versions.

Member

philr commented May 22, 2016

The test is failing at around the point when times can no longer be represented as 32-bit signed integers (the transition following the one that is failing is greater than 2^32 - 1).

The tzinfo-data tests rely on the zic and zdump tools from the IANA Time Zone Database. The failure therefore probably means that you have old versions of these tools that only support 32-bit times (I think MacOS X still ships with ancient 32-bit only versions).

I'd suggest compiling the latest version of the Time Zone Code package from the IANA Time Zone Database (currently tzcode2016d.tar.gz). Check the included README for build instructions. This will give you up to date versions of zic and zdump, which you'll need to add to your PATH ahead of the system versions.

@wwood

This comment has been minimized.

Show comment
Hide comment
@wwood

wwood May 22, 2016

Hmm. I'm running these versions which aren't IANA, I guess. They are not out of date.

$ zic --version
zic (GNU libc) 2.23
$ zdump --version
zdump (GNU libc) 2.23

Given 2.23 was released this year it seems unlikely that there is a 32-bit issue? I don't know anything about timezone software, any ideas? Is there a way that I can reproduce this outside Ruby?

ta

wwood commented May 22, 2016

Hmm. I'm running these versions which aren't IANA, I guess. They are not out of date.

$ zic --version
zic (GNU libc) 2.23
$ zdump --version
zdump (GNU libc) 2.23

Given 2.23 was released this year it seems unlikely that there is a 32-bit issue? I don't know anything about timezone software, any ideas? Is there a way that I can reproduce this outside Ruby?

ta

@philr

This comment has been minimized.

Show comment
Hide comment
@philr

philr May 22, 2016

Member

glibc 2.23 appears to bundle copies of zic and zdump from the IANA TIme Zone Database tzcode2015g release. tzcode2015g is new enough to support 64-bit timestamps.

If you want to confirm that zic is producing files with 64-bit transitions, you can run the following from an empty directory:

curl https://www.iana.org/time-zones/repository/releases/tzdata2016d.tar.gz | tar xz
zic -d . africa
echo `head -c 5 Africa/Casablanca`

This will download the 2016d tzdata release, compile the africa file and then output the header of the compiled Africa/Casablanca file. If the header is TZif2 or TZif3, then zic is generating files with 64-bit transition times. If you only see TZif (actually TZif followed by a null byte in the file), then zic is generating files that only include 32-bit transitions.

Looking again at the test failure in your initial comment, it appears that it is actually Ruby and not zdump that is producing the incorrect value. The value Ruby is producing is consistent with a version of the Africa/Casablanca zone from before version 2015e (tzinfo-data v1.2015.5). It is therefore possible that the tests are picking up an older installed set of data instead of the files in the tzinfo-data distribution being tested.

How are you executing the tests? The expected/supported way is to run bundle exec rake test. If you are not using Bundler, then you need to make sure that the lib directory from the tzinfo-data distribution being tested is on the Ruby load path prior to executing the tests (require 'tzinfo/data' needs to load the file being tested instead of activating an installed gem).

Member

philr commented May 22, 2016

glibc 2.23 appears to bundle copies of zic and zdump from the IANA TIme Zone Database tzcode2015g release. tzcode2015g is new enough to support 64-bit timestamps.

If you want to confirm that zic is producing files with 64-bit transitions, you can run the following from an empty directory:

curl https://www.iana.org/time-zones/repository/releases/tzdata2016d.tar.gz | tar xz
zic -d . africa
echo `head -c 5 Africa/Casablanca`

This will download the 2016d tzdata release, compile the africa file and then output the header of the compiled Africa/Casablanca file. If the header is TZif2 or TZif3, then zic is generating files with 64-bit transition times. If you only see TZif (actually TZif followed by a null byte in the file), then zic is generating files that only include 32-bit transitions.

Looking again at the test failure in your initial comment, it appears that it is actually Ruby and not zdump that is producing the incorrect value. The value Ruby is producing is consistent with a version of the Africa/Casablanca zone from before version 2015e (tzinfo-data v1.2015.5). It is therefore possible that the tests are picking up an older installed set of data instead of the files in the tzinfo-data distribution being tested.

How are you executing the tests? The expected/supported way is to run bundle exec rake test. If you are not using Bundler, then you need to make sure that the lib directory from the tzinfo-data distribution being tested is on the Ruby load path prior to executing the tests (require 'tzinfo/data' needs to load the file being tested instead of activating an installed gem).

@wwood

This comment has been minimized.

Show comment
Hide comment
@wwood

wwood May 23, 2016

Hmm, I'm just running rake test, but this is from inside a container (all Guix packages are built this way), with the following gems. I tried with bundle exec rake test, got the same thing.

$ gem list
bigdecimal (1.2.8)
did_you_mean (1.0.0)
io-console (0.4.5)
json (1.8.3)
minitest (5.8.3)
net-telnet (0.1.1)
power_assert (0.2.6)
psych (2.0.17)
rake (10.4.2)
rdoc (4.2.1)
test-unit (3.1.5)
thread_safe (0.3.5)
tzinfo (1.2.2)

I also tried the same thing on Ubuntu newest, and got the same thing, but with some more warnings. From a fresh untar of the gem,

/tmp/tzinfo-data-1.2016.4$ bundle exec rake test
Ignoring libxml-ruby-2.8.0 because its extensions are not built.  Try: gem pristine libxml-ruby --version 2.8.0
WARNING: Private key not found. Not signing gem file.
["/home/ben/.rvm/gems/ruby-2.3.0/gems/thread_safe-0.3.5/lib", "/home/ben/.rvm/gems/ruby-2.3.0/gems/minitest-5.8.4/lib", "/tmp/tzinfo-data-1.2016.4/lib", "/home/ben/.rvm/gems/ruby-2.3.0/gems/tzinfo-1.2.2/lib", "/home/ben/.rvm/gems/ruby-2.3.0/gems/rake-11.1.2/lib", "/home/ben/.rvm/gems/ruby-2.3.0/gems/bundler-1.11.2/lib", "/home/ben/.rvm/rubies/ruby-2.3.0/lib/ruby/site_ruby/2.3.0", "/home/ben/.rvm/rubies/ruby-2.3.0/lib/ruby/site_ruby/2.3.0/x86_64-linux", "/home/ben/.rvm/rubies/ruby-2.3.0/lib/ruby/site_ruby", "/home/ben/.rvm/rubies/ruby-2.3.0/lib/ruby/vendor_ruby/2.3.0", "/home/ben/.rvm/rubies/ruby-2.3.0/lib/ruby/vendor_ruby/2.3.0/x86_64-linux", "/home/ben/.rvm/rubies/ruby-2.3.0/lib/ruby/vendor_ruby", "/home/ben/.rvm/rubies/ruby-2.3.0/lib/ruby/2.3.0", "/home/ben/.rvm/rubies/ruby-2.3.0/lib/ruby/2.3.0/x86_64-linux"]
Run options: --seed 15455

# Running:

.......warning: "/tmp/tzinfo-data-1.2016.4/data/asia", line 1752: time zone abbreviation differs from POSIX standard (+05)
warning: "/tmp/tzinfo-data-1.2016.4/data/asia", line 1753: time zone abbreviation differs from POSIX standard (+07) (rule from "/tmp/tzinfo-data-1.2016.4/data/asia", line 80)
warning: "/tmp/tzinfo-data-1.2016.4/data/asia", line 1753: time zone abbreviation differs from POSIX standard (+06) (rule from "/tmp/tzinfo-data-1.2016.4/data/asia", line 81)
warning: "/tmp/tzinfo-data-1.2016.4/data/asia", line 1759: time zone abbreviation differs from POSIX standard (+04)
warning: "/tmp/tzinfo-data-1.2016.4/data/asia", line 1760: time zone abbreviation differs from POSIX standard (+05)
warning: "/tmp/tzinfo-data-1.2016.4/data/asia", line 1761: time zone abbreviation differs from POSIX standard (+06)
warning: "/tmp/tzinfo-data-1.2016.4/data/asia", line 1771: time zone abbreviation differs from POSIX standard (+04)
warning: "/tmp/tzinfo-data-1.2016.4/data/asia", line 1772: time zone abbreviation differs from POSIX standard (+05)
warning: "/tmp/tzinfo-data-1.2016.4/data/asia", line 1773: time zone abbreviation differs from POSIX standard (+06)
warning: "/tmp/tzinfo-data-1.2016.4/data/asia", line 1785: time zone abbreviation differs from POSIX standard (+04)
warning: "/tmp/tzinfo-data-1.2016.4/data/asia", line 1786: time zone abbreviation differs from POSIX standard (+05)
warning: "/tmp/tzinfo-data-1.2016.4/data/asia", line 1788: time zone abbreviation differs from POSIX standard (+06)
warning: "/tmp/tzinfo-data-1.2016.4/data/asia", line 1799: time zone abbreviation differs from POSIX standard (+04)
warning: "/tmp/tzinfo-data-1.2016.4/data/asia", line 1800: time zone abbreviation differs from POSIX standard (+05)
warning: "/tmp/tzinfo-data-1.2016.4/data/asia", line 1801: time zone abbreviation differs from POSIX standard (+06)
warning: "/tmp/tzinfo-data-1.2016.4/data/europe", line 2555: time zone abbreviation differs from POSIX standard (+03)
warning: "/tmp/tzinfo-data-1.2016.4/data/europe", line 2556: time zone abbreviation differs from POSIX standard (+05) (rule from "/tmp/tzinfo-data-1.2016.4/data/europe", line 599)
warning: "/tmp/tzinfo-data-1.2016.4/data/europe", line 2556: time zone abbreviation differs from POSIX standard (+04) (rule from "/tmp/tzinfo-data-1.2016.4/data/europe", line 600)
warning: "/tmp/tzinfo-data-1.2016.4/data/europe", line 2587: time zone abbreviation differs from POSIX standard (+03)
warning: "/tmp/tzinfo-data-1.2016.4/data/europe", line 2588: time zone abbreviation differs from POSIX standard (+05) (rule from "/tmp/tzinfo-data-1.2016.4/data/europe", line 599)
warning: "/tmp/tzinfo-data-1.2016.4/data/europe", line 2588: time zone abbreviation differs from POSIX standard (+04) (rule from "/tmp/tzinfo-data-1.2016.4/data/europe", line 600)
warning: "/tmp/tzinfo-data-1.2016.4/data/europe", line 2629: time zone abbreviation differs from POSIX standard (+03)
warning: "/tmp/tzinfo-data-1.2016.4/data/europe", line 2630: time zone abbreviation differs from POSIX standard (+05) (rule from "/tmp/tzinfo-data-1.2016.4/data/europe", line 599)
warning: "/tmp/tzinfo-data-1.2016.4/data/europe", line 2630: time zone abbreviation differs from POSIX standard (+04) (rule from "/tmp/tzinfo-data-1.2016.4/data/europe", line 600)
warning: "/tmp/tzinfo-data-1.2016.4/data/europe", line 2632: time zone abbreviation differs from POSIX standard (+02) (rule from "/tmp/tzinfo-data-1.2016.4/data/europe", line 603)
warning: "/tmp/tzinfo-data-1.2016.4/data/europe", line 2713: time zone abbreviation differs from POSIX standard (+06)
warning: "/tmp/tzinfo-data-1.2016.4/data/europe", line 2714: time zone abbreviation differs from POSIX standard (+08) (rule from "/tmp/tzinfo-data-1.2016.4/data/europe", line 599)
warning: "/tmp/tzinfo-data-1.2016.4/data/europe", line 2714: time zone abbreviation differs from POSIX standard (+07) (rule from "/tmp/tzinfo-data-1.2016.4/data/europe", line 600)
warning: "/tmp/tzinfo-data-1.2016.4/data/europe", line 2775: time zone abbreviation differs from POSIX standard (+06)
warning: "/tmp/tzinfo-data-1.2016.4/data/europe", line 2776: time zone abbreviation differs from POSIX standard (+08) (rule from "/tmp/tzinfo-data-1.2016.4/data/europe", line 599)
warning: "/tmp/tzinfo-data-1.2016.4/data/europe", line 2776: time zone abbreviation differs from POSIX standard (+07) (rule from "/tmp/tzinfo-data-1.2016.4/data/europe", line 600)
F..

Finished in 30.242489s, 0.3307 runs/s, 5074.5492 assertions/s.

  1) Failure:
TCDefinitions#test_all [/tmp/tzinfo-data-1.2016.4/test/tc_definitions.rb:55]:
Local times don't match:
zdump:         Africa/Casablanca 2037-10-25T01:59:59+00:00 UTC 2037-10-25T02:59:59+00:00 WEST is_dst=1
tzinfo (u->l): Africa/Casablanca 2037-10-25T01:59:59+00:00 UTC 2037-10-25T01:59:59+00:00 WET is_dst=0.
--- expected
+++ actual
@@ -1 +1 @@
-#<DateTime: 2037-10-25T02:59:59+00:00 ((2465357j,10799s,0n),+0s,2299161j)>
+#<DateTime: 2037-10-25T01:59:59+00:00 ((2465357j,7199s,0n),+0s,2299161j)>


10 runs, 153467 assertions, 1 failures, 0 errors, 0 skips
rake aborted!
Command failed with status (1): [ruby -w -I"lib:/home/ben/.rvm/gems/ruby-2.3.0/gems/tzinfo-1.2.2/lib" -I"/home/ben/.rvm/gems/ruby-2.3.0/gems/rake-11.1.2/lib" "/home/ben/.rvm/gems/ruby-2.3.0/gems/rake-11.1.2/lib/rake/rake_test_loader.rb" "/tmp/tzinfo-data-1.2016.4/test/ts_all.rb" ]
/home/ben/.rvm/gems/ruby-2.3.0/bin/ruby_executable_hooks:15:in `eval'
/home/ben/.rvm/gems/ruby-2.3.0/bin/ruby_executable_hooks:15:in `<main>'
Tasks: TOP => test
(See full trace by running task with --trace)

I also tried the curl ... you suggested and got

$ echo `head -c 5 Africa/Casablanca`
TZif2

soz..

wwood commented May 23, 2016

Hmm, I'm just running rake test, but this is from inside a container (all Guix packages are built this way), with the following gems. I tried with bundle exec rake test, got the same thing.

$ gem list
bigdecimal (1.2.8)
did_you_mean (1.0.0)
io-console (0.4.5)
json (1.8.3)
minitest (5.8.3)
net-telnet (0.1.1)
power_assert (0.2.6)
psych (2.0.17)
rake (10.4.2)
rdoc (4.2.1)
test-unit (3.1.5)
thread_safe (0.3.5)
tzinfo (1.2.2)

I also tried the same thing on Ubuntu newest, and got the same thing, but with some more warnings. From a fresh untar of the gem,

/tmp/tzinfo-data-1.2016.4$ bundle exec rake test
Ignoring libxml-ruby-2.8.0 because its extensions are not built.  Try: gem pristine libxml-ruby --version 2.8.0
WARNING: Private key not found. Not signing gem file.
["/home/ben/.rvm/gems/ruby-2.3.0/gems/thread_safe-0.3.5/lib", "/home/ben/.rvm/gems/ruby-2.3.0/gems/minitest-5.8.4/lib", "/tmp/tzinfo-data-1.2016.4/lib", "/home/ben/.rvm/gems/ruby-2.3.0/gems/tzinfo-1.2.2/lib", "/home/ben/.rvm/gems/ruby-2.3.0/gems/rake-11.1.2/lib", "/home/ben/.rvm/gems/ruby-2.3.0/gems/bundler-1.11.2/lib", "/home/ben/.rvm/rubies/ruby-2.3.0/lib/ruby/site_ruby/2.3.0", "/home/ben/.rvm/rubies/ruby-2.3.0/lib/ruby/site_ruby/2.3.0/x86_64-linux", "/home/ben/.rvm/rubies/ruby-2.3.0/lib/ruby/site_ruby", "/home/ben/.rvm/rubies/ruby-2.3.0/lib/ruby/vendor_ruby/2.3.0", "/home/ben/.rvm/rubies/ruby-2.3.0/lib/ruby/vendor_ruby/2.3.0/x86_64-linux", "/home/ben/.rvm/rubies/ruby-2.3.0/lib/ruby/vendor_ruby", "/home/ben/.rvm/rubies/ruby-2.3.0/lib/ruby/2.3.0", "/home/ben/.rvm/rubies/ruby-2.3.0/lib/ruby/2.3.0/x86_64-linux"]
Run options: --seed 15455

# Running:

.......warning: "/tmp/tzinfo-data-1.2016.4/data/asia", line 1752: time zone abbreviation differs from POSIX standard (+05)
warning: "/tmp/tzinfo-data-1.2016.4/data/asia", line 1753: time zone abbreviation differs from POSIX standard (+07) (rule from "/tmp/tzinfo-data-1.2016.4/data/asia", line 80)
warning: "/tmp/tzinfo-data-1.2016.4/data/asia", line 1753: time zone abbreviation differs from POSIX standard (+06) (rule from "/tmp/tzinfo-data-1.2016.4/data/asia", line 81)
warning: "/tmp/tzinfo-data-1.2016.4/data/asia", line 1759: time zone abbreviation differs from POSIX standard (+04)
warning: "/tmp/tzinfo-data-1.2016.4/data/asia", line 1760: time zone abbreviation differs from POSIX standard (+05)
warning: "/tmp/tzinfo-data-1.2016.4/data/asia", line 1761: time zone abbreviation differs from POSIX standard (+06)
warning: "/tmp/tzinfo-data-1.2016.4/data/asia", line 1771: time zone abbreviation differs from POSIX standard (+04)
warning: "/tmp/tzinfo-data-1.2016.4/data/asia", line 1772: time zone abbreviation differs from POSIX standard (+05)
warning: "/tmp/tzinfo-data-1.2016.4/data/asia", line 1773: time zone abbreviation differs from POSIX standard (+06)
warning: "/tmp/tzinfo-data-1.2016.4/data/asia", line 1785: time zone abbreviation differs from POSIX standard (+04)
warning: "/tmp/tzinfo-data-1.2016.4/data/asia", line 1786: time zone abbreviation differs from POSIX standard (+05)
warning: "/tmp/tzinfo-data-1.2016.4/data/asia", line 1788: time zone abbreviation differs from POSIX standard (+06)
warning: "/tmp/tzinfo-data-1.2016.4/data/asia", line 1799: time zone abbreviation differs from POSIX standard (+04)
warning: "/tmp/tzinfo-data-1.2016.4/data/asia", line 1800: time zone abbreviation differs from POSIX standard (+05)
warning: "/tmp/tzinfo-data-1.2016.4/data/asia", line 1801: time zone abbreviation differs from POSIX standard (+06)
warning: "/tmp/tzinfo-data-1.2016.4/data/europe", line 2555: time zone abbreviation differs from POSIX standard (+03)
warning: "/tmp/tzinfo-data-1.2016.4/data/europe", line 2556: time zone abbreviation differs from POSIX standard (+05) (rule from "/tmp/tzinfo-data-1.2016.4/data/europe", line 599)
warning: "/tmp/tzinfo-data-1.2016.4/data/europe", line 2556: time zone abbreviation differs from POSIX standard (+04) (rule from "/tmp/tzinfo-data-1.2016.4/data/europe", line 600)
warning: "/tmp/tzinfo-data-1.2016.4/data/europe", line 2587: time zone abbreviation differs from POSIX standard (+03)
warning: "/tmp/tzinfo-data-1.2016.4/data/europe", line 2588: time zone abbreviation differs from POSIX standard (+05) (rule from "/tmp/tzinfo-data-1.2016.4/data/europe", line 599)
warning: "/tmp/tzinfo-data-1.2016.4/data/europe", line 2588: time zone abbreviation differs from POSIX standard (+04) (rule from "/tmp/tzinfo-data-1.2016.4/data/europe", line 600)
warning: "/tmp/tzinfo-data-1.2016.4/data/europe", line 2629: time zone abbreviation differs from POSIX standard (+03)
warning: "/tmp/tzinfo-data-1.2016.4/data/europe", line 2630: time zone abbreviation differs from POSIX standard (+05) (rule from "/tmp/tzinfo-data-1.2016.4/data/europe", line 599)
warning: "/tmp/tzinfo-data-1.2016.4/data/europe", line 2630: time zone abbreviation differs from POSIX standard (+04) (rule from "/tmp/tzinfo-data-1.2016.4/data/europe", line 600)
warning: "/tmp/tzinfo-data-1.2016.4/data/europe", line 2632: time zone abbreviation differs from POSIX standard (+02) (rule from "/tmp/tzinfo-data-1.2016.4/data/europe", line 603)
warning: "/tmp/tzinfo-data-1.2016.4/data/europe", line 2713: time zone abbreviation differs from POSIX standard (+06)
warning: "/tmp/tzinfo-data-1.2016.4/data/europe", line 2714: time zone abbreviation differs from POSIX standard (+08) (rule from "/tmp/tzinfo-data-1.2016.4/data/europe", line 599)
warning: "/tmp/tzinfo-data-1.2016.4/data/europe", line 2714: time zone abbreviation differs from POSIX standard (+07) (rule from "/tmp/tzinfo-data-1.2016.4/data/europe", line 600)
warning: "/tmp/tzinfo-data-1.2016.4/data/europe", line 2775: time zone abbreviation differs from POSIX standard (+06)
warning: "/tmp/tzinfo-data-1.2016.4/data/europe", line 2776: time zone abbreviation differs from POSIX standard (+08) (rule from "/tmp/tzinfo-data-1.2016.4/data/europe", line 599)
warning: "/tmp/tzinfo-data-1.2016.4/data/europe", line 2776: time zone abbreviation differs from POSIX standard (+07) (rule from "/tmp/tzinfo-data-1.2016.4/data/europe", line 600)
F..

Finished in 30.242489s, 0.3307 runs/s, 5074.5492 assertions/s.

  1) Failure:
TCDefinitions#test_all [/tmp/tzinfo-data-1.2016.4/test/tc_definitions.rb:55]:
Local times don't match:
zdump:         Africa/Casablanca 2037-10-25T01:59:59+00:00 UTC 2037-10-25T02:59:59+00:00 WEST is_dst=1
tzinfo (u->l): Africa/Casablanca 2037-10-25T01:59:59+00:00 UTC 2037-10-25T01:59:59+00:00 WET is_dst=0.
--- expected
+++ actual
@@ -1 +1 @@
-#<DateTime: 2037-10-25T02:59:59+00:00 ((2465357j,10799s,0n),+0s,2299161j)>
+#<DateTime: 2037-10-25T01:59:59+00:00 ((2465357j,7199s,0n),+0s,2299161j)>


10 runs, 153467 assertions, 1 failures, 0 errors, 0 skips
rake aborted!
Command failed with status (1): [ruby -w -I"lib:/home/ben/.rvm/gems/ruby-2.3.0/gems/tzinfo-1.2.2/lib" -I"/home/ben/.rvm/gems/ruby-2.3.0/gems/rake-11.1.2/lib" "/home/ben/.rvm/gems/ruby-2.3.0/gems/rake-11.1.2/lib/rake/rake_test_loader.rb" "/tmp/tzinfo-data-1.2016.4/test/ts_all.rb" ]
/home/ben/.rvm/gems/ruby-2.3.0/bin/ruby_executable_hooks:15:in `eval'
/home/ben/.rvm/gems/ruby-2.3.0/bin/ruby_executable_hooks:15:in `<main>'
Tasks: TOP => test
(See full trace by running task with --trace)

I also tried the curl ... you suggested and got

$ echo `head -c 5 Africa/Casablanca`
TZif2

soz..

@philr

This comment has been minimized.

Show comment
Hide comment
@philr

philr May 24, 2016

Member

I've looked into this further. The test failure is caused by using an old version of zdump and not anything on the Ruby side as I suggested in my last comment.

In 2037, Africa/Casablanca is supposed to revert from DST to standard time on October 4 (see https://github.com/eggert/tz/blob/2016d/africa#L892). The Glibc 2.23 version of zdump incorrectly shows DST ending on October 25:

$ /usr/bin/zdump --version
zdump (Ubuntu GLIBC 2.23-0ubuntu3) 2.23
$ /usr/bin/zdump -v -c 2037,2038 ~/tz/etc/zoneinfo/Africa/Casablanca
/home/ubuntu/tz/etc/zoneinfo/Africa/Casablanca  -9223372036854775808 = NULL
/home/ubuntu/tz/etc/zoneinfo/Africa/Casablanca  -9223372036854689408 = NULL
/home/ubuntu/tz/etc/zoneinfo/Africa/Casablanca  Sun Mar 29 01:59:59 2037 UT = Sun Mar 29 01:59:59 2037 WET isdst=0 gmtoff=0
/home/ubuntu/tz/etc/zoneinfo/Africa/Casablanca  Sun Mar 29 02:00:00 2037 UT = Sun Mar 29 03:00:00 2037 WEST isdst=1 gmtoff=3600
/home/ubuntu/tz/etc/zoneinfo/Africa/Casablanca  Sun Oct 25 01:59:59 2037 UT = Sun Oct 25 02:59:59 2037 WEST isdst=1 gmtoff=3600
/home/ubuntu/tz/etc/zoneinfo/Africa/Casablanca  Sun Oct 25 02:00:00 2037 UT = Sun Oct 25 02:00:00 2037 WET isdst=0 gmtoff=0
/home/ubuntu/tz/etc/zoneinfo/Africa/Casablanca  9223372036854689407 = NULL
/home/ubuntu/tz/etc/zoneinfo/Africa/Casablanca  9223372036854775807 = NULL

However, the IANA Time Zone Database tzcode 2016d release gets the correct date:

$ ~/tz/etc/zdump --version
zdump (tzcode) 2016d
$ ~/tz/etc/zdump -v -c 2037,2038 ~/tz/etc/zoneinfo/Africa/Casablanca
/home/ubuntu/tz/etc/zoneinfo/Africa/Casablanca  -9223372036854775808 = NULL
/home/ubuntu/tz/etc/zoneinfo/Africa/Casablanca  -9223372036854689408 = NULL
/home/ubuntu/tz/etc/zoneinfo/Africa/Casablanca  Sun Mar 29 01:59:59 2037 UT = Sun Mar 29 01:59:59 2037 WET isdst=0 gmtoff=0
/home/ubuntu/tz/etc/zoneinfo/Africa/Casablanca  Sun Mar 29 02:00:00 2037 UT = Sun Mar 29 03:00:00 2037 WEST isdst=1 gmtoff=3600
/home/ubuntu/tz/etc/zoneinfo/Africa/Casablanca  Sun Oct  4 01:59:59 2037 UT = Sun Oct  4 02:59:59 2037 WEST isdst=1 gmtoff=3600
/home/ubuntu/tz/etc/zoneinfo/Africa/Casablanca  Sun Oct  4 02:00:00 2037 UT = Sun Oct  4 02:00:00 2037 WET isdst=0 gmtoff=0
/home/ubuntu/tz/etc/zoneinfo/Africa/Casablanca  9223372036854689407 = NULL
/home/ubuntu/tz/etc/zoneinfo/Africa/Casablanca  9223372036854775807 = NULL

The test case that is failing is attempting to verify each pair of times in the zdump output. It reads Sun Oct 25 01:59:59 2037 UT from the zdump output and converts it to local Casablanca time. Since this time is actually 3 weeks after DST ends and not 1 second before DST ends, the Ruby conversion (correctly) returns a non-DST result that is not a match for the zdump output.

I'll look into making the tzinfo-data test suite automatically download and compile the matching version of tzcode from the IANA Time Zone Database, which should avoid issues like this in the future.

In the mean time though, you'll need to run the tests using a more recent build of zdump. Releases of tzcode are made at the same time as tzdata and have matching version numbers. I'd recommend always using the version of tzcode that corresponds to the version of tzinfo-data being tested (e.g. tzcode 2016d for tzinfo-data 1.2016.4).

Member

philr commented May 24, 2016

I've looked into this further. The test failure is caused by using an old version of zdump and not anything on the Ruby side as I suggested in my last comment.

In 2037, Africa/Casablanca is supposed to revert from DST to standard time on October 4 (see https://github.com/eggert/tz/blob/2016d/africa#L892). The Glibc 2.23 version of zdump incorrectly shows DST ending on October 25:

$ /usr/bin/zdump --version
zdump (Ubuntu GLIBC 2.23-0ubuntu3) 2.23
$ /usr/bin/zdump -v -c 2037,2038 ~/tz/etc/zoneinfo/Africa/Casablanca
/home/ubuntu/tz/etc/zoneinfo/Africa/Casablanca  -9223372036854775808 = NULL
/home/ubuntu/tz/etc/zoneinfo/Africa/Casablanca  -9223372036854689408 = NULL
/home/ubuntu/tz/etc/zoneinfo/Africa/Casablanca  Sun Mar 29 01:59:59 2037 UT = Sun Mar 29 01:59:59 2037 WET isdst=0 gmtoff=0
/home/ubuntu/tz/etc/zoneinfo/Africa/Casablanca  Sun Mar 29 02:00:00 2037 UT = Sun Mar 29 03:00:00 2037 WEST isdst=1 gmtoff=3600
/home/ubuntu/tz/etc/zoneinfo/Africa/Casablanca  Sun Oct 25 01:59:59 2037 UT = Sun Oct 25 02:59:59 2037 WEST isdst=1 gmtoff=3600
/home/ubuntu/tz/etc/zoneinfo/Africa/Casablanca  Sun Oct 25 02:00:00 2037 UT = Sun Oct 25 02:00:00 2037 WET isdst=0 gmtoff=0
/home/ubuntu/tz/etc/zoneinfo/Africa/Casablanca  9223372036854689407 = NULL
/home/ubuntu/tz/etc/zoneinfo/Africa/Casablanca  9223372036854775807 = NULL

However, the IANA Time Zone Database tzcode 2016d release gets the correct date:

$ ~/tz/etc/zdump --version
zdump (tzcode) 2016d
$ ~/tz/etc/zdump -v -c 2037,2038 ~/tz/etc/zoneinfo/Africa/Casablanca
/home/ubuntu/tz/etc/zoneinfo/Africa/Casablanca  -9223372036854775808 = NULL
/home/ubuntu/tz/etc/zoneinfo/Africa/Casablanca  -9223372036854689408 = NULL
/home/ubuntu/tz/etc/zoneinfo/Africa/Casablanca  Sun Mar 29 01:59:59 2037 UT = Sun Mar 29 01:59:59 2037 WET isdst=0 gmtoff=0
/home/ubuntu/tz/etc/zoneinfo/Africa/Casablanca  Sun Mar 29 02:00:00 2037 UT = Sun Mar 29 03:00:00 2037 WEST isdst=1 gmtoff=3600
/home/ubuntu/tz/etc/zoneinfo/Africa/Casablanca  Sun Oct  4 01:59:59 2037 UT = Sun Oct  4 02:59:59 2037 WEST isdst=1 gmtoff=3600
/home/ubuntu/tz/etc/zoneinfo/Africa/Casablanca  Sun Oct  4 02:00:00 2037 UT = Sun Oct  4 02:00:00 2037 WET isdst=0 gmtoff=0
/home/ubuntu/tz/etc/zoneinfo/Africa/Casablanca  9223372036854689407 = NULL
/home/ubuntu/tz/etc/zoneinfo/Africa/Casablanca  9223372036854775807 = NULL

The test case that is failing is attempting to verify each pair of times in the zdump output. It reads Sun Oct 25 01:59:59 2037 UT from the zdump output and converts it to local Casablanca time. Since this time is actually 3 weeks after DST ends and not 1 second before DST ends, the Ruby conversion (correctly) returns a non-DST result that is not a match for the zdump output.

I'll look into making the tzinfo-data test suite automatically download and compile the matching version of tzcode from the IANA Time Zone Database, which should avoid issues like this in the future.

In the mean time though, you'll need to run the tests using a more recent build of zdump. Releases of tzcode are made at the same time as tzdata and have matching version numbers. I'd recommend always using the version of tzcode that corresponds to the version of tzinfo-data being tested (e.g. tzcode 2016d for tzinfo-data 1.2016.4).

@wwood

This comment has been minimized.

Show comment
Hide comment
@wwood

wwood May 24, 2016

Thanks for looking into this even further.

So glibc is at fault, and this issue will presumably be fixed in time. Anyone using your code is in the clear then. If I was you maybe you could add an explanation when this particular test fails? And maybe lobby glibc peeps to update their IANA db?

Downloading the IANA database during testing would actually entail further work for me the packager because tests are run inside a container that purposely lacks network access. Also, it is more work for you...

For now I'll simply skip this test in Guix because it isn't a bug with tzinfo-data, and then re-enable it later on.

wwood commented May 24, 2016

Thanks for looking into this even further.

So glibc is at fault, and this issue will presumably be fixed in time. Anyone using your code is in the clear then. If I was you maybe you could add an explanation when this particular test fails? And maybe lobby glibc peeps to update their IANA db?

Downloading the IANA database during testing would actually entail further work for me the packager because tests are run inside a container that purposely lacks network access. Also, it is more work for you...

For now I'll simply skip this test in Guix because it isn't a bug with tzinfo-data, and then re-enable it later on.

@philr

This comment has been minimized.

Show comment
Hide comment
@philr

philr May 30, 2016

Member

I think I'll probably make the tests default to downloading and compiling zdump from the IANA time zone database, but provide an option to override this if you want to use your own version of zdump (with suitable warnings).

It doesn't appear to be quite as simple as the zdump code being out of date in glibc. zdump.c in glibc 2.23 is identical to zdump.c in tzcode2015g. However compiling and running zdump from tzcode2015g produces the correct result.

I have raised bug #1587128 for this issue against the Ubuntu glibc package (since I've only reproduced it with the Ubuntu binaries).

Member

philr commented May 30, 2016

I think I'll probably make the tests default to downloading and compiling zdump from the IANA time zone database, but provide an option to override this if you want to use your own version of zdump (with suitable warnings).

It doesn't appear to be quite as simple as the zdump code being out of date in glibc. zdump.c in glibc 2.23 is identical to zdump.c in tzcode2015g. However compiling and running zdump from tzcode2015g produces the correct result.

I have raised bug #1587128 for this issue against the Ubuntu glibc package (since I've only reproduced it with the Ubuntu binaries).

@philr philr closed this May 30, 2016

@wwood

This comment has been minimized.

Show comment
Hide comment
@wwood

wwood May 31, 2016

alrighty, good luck.

wwood commented May 31, 2016

alrighty, good luck.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment