Repository navigation
test failure #10
Description
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.
Activity
philr commentedon 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
zicandzdumptools 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
zicandzdump, which you'll need to add to yourPATHahead of the system versions.wwood commentedon May 22, 2016
Hmm. I'm running these versions which aren't IANA, I guess. They are not out of date.
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 commentedon May 22, 2016
glibc 2.23 appears to bundle copies of
zicandzdumpfrom the IANA TIme Zone Database tzcode2015g release. tzcode2015g is new enough to support 64-bit timestamps.If you want to confirm that
zicis producing files with 64-bit transitions, you can run the following from an empty directory: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
TZif2orTZif3, thenzicis generating files with 64-bit transition times. If you only seeTZif(actually TZif followed by a null byte in the file), thenzicis 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
zdumpthat 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 thelibdirectory 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 commentedon 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 withbundle exec rake test, got the same thing.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,
I also tried the
curl ...you suggested and gotsoz..
philr commentedon May 24, 2016
I've looked into this further. The test failure is caused by using an old version of
zdumpand 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
zdumpincorrectly shows DST ending on October 25:However, the IANA Time Zone Database tzcode 2016d release gets the correct date:
The test case that is failing is attempting to verify each pair of times in the
zdumpoutput. It reads Sun Oct 25 01:59:59 2037 UT from thezdumpoutput 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 thezdumpoutput.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 commentedon 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 commentedon 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).
wwood commentedon May 31, 2016
alrighty, good luck.