Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
test failure #10
Hi, I'm attempting to package tzinfo-data for Guix, and ran into this test failure. Any ideas?
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
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
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?
glibc 2.23 appears to bundle copies of
If you want to confirm that
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
Looking again at the test failure in your initial comment, it appears that it is actually Ruby and not
How are you executing the tests? The expected/supported way is to run
Hmm, I'm just running
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
I've looked into this further. The test failure is caused by using an old version of
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
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
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
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.
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).