Weird test failure in clock_cast_test/local_t.pass.cpp:67

[JonasToth]

Hi,

I am currently writing an package for gentoo for this library. Part of that exercise is adding the unit tests to package testing to ensure everything works as expected and such.

Gentoo uses a special CMAKE_BUILD_TYPE=Gentoo, that leads to the following error:

# ./clock_cast_test_pass_local_t_bin
> clock_cast_test_pass_local_t_bin: <portage-path>/test/clock_cast_test/local_t.pass.cpp:67: int main(): Assertion `clock_cast<local_t>(ut) == lu' failed.

A bit of experimentation indicates, that any "invalid" CMAKE_BUILD_TYPE=Foo triggers this behaviour.

How to reproduce on Gentoo:

$ git clone ...
$ mkdir build && cd build
$ ccmake .. \
        -G Ninja \
        -DCMAKE_BUILD_TYPE=Foo \
        -DENABLE_DATE_TESTING=ON \
        -DBUILD_TZ_LIB=ON \
        -DUSE_SYSTEM_TZ_DB=ON
$ ninja testit

I am very, very puzzle by that result. If anything else, this is just for reference if anyone hits the same issue.

[HowardHinnant]

This likely means that the OS doesn't supply leap second information as part of its native tz database. Or that they supply the information but this lib isn't picking it up. If it is the latter, I can fix that.

If you could locate the zoneinfo/ directory for me that would help greatly. If that directory contains the file leapseconds, I can fix this. I note that I need to make the same fix for Apple platforms, so this fix is going in regardless. But I don't know if it will fix gentoo.

IANA only relatively recently started shipping leapseconds, I need to catch up on that front.

[JonasToth]

Thanks for your fast reply!

One additional oddity is, that the whole process works when building "normal", without that package management stuff, and if the build-type is not "Gentoo", but e.g. "Release" (i have no clue why! i tried to reproduce on ubuntu, but there its fine).

I created a tar with all the zoneinfo in the attachement. gentoo_zoneinfo.tar.zip

There is a list of leap seconds, not sure if that is exactly how it should be. It seems to be identical to the directory present in ubuntu (where everything works). It seems very likely, that its an issue with the package manager build system.

Edit question: Is this information read on runtime, or is it an compile-time thing?

[HowardHinnant]

Wow, I can't believe that somebody thought it was a good idea to rename leapseconds to leap-seconds.list...

If it works normally without the package management stuff, I'll bet the package manager is the piece of software doing that file rename. That file is identical (except for name) to what IANA ships.

[HowardHinnant]

Oops, hold the phone. My bad. IANA ships leap-seconds.list too. Ok, I've got work to do. Thanks much for reporting this.

[JonasToth]

Wow, I can't believe that somebody thought it was a good idea to rename leapseconds to leap-seconds.list...

That seems to be a linux thing? Ubuntu 18.04 has it, too. Update: Ok. Would this be a fix on your side?

If it works normally without the package management stuff, I'll bet the package manager is the piece of software doing that file rename. That file is identical (except for name) to what IANA ships.

But how is the information about the file transmitted? Is there something in the libc, that passes that through or do you have these paths somewhere in your code? Somehow that stuff seems to work sometimes on these machines. And i did not find any explicit time-related changes happening in the code, that does all the infrastructure for building.

[HowardHinnant]

Yes, this is my bug. It may be the weekend before I can get it fixed.

Quite frankly I'm not sure of all the details yet. IANA ships both files, and it appears that sometimes OS's deliver one or the other. I need to look for both. And there's a 3rd (older) way that IANA ships this information that I already handle. The information is sometimes buried under zoneinfo/right/UTC.

[JonasToth]

Ok. No pressure from my side! Once you have a fix, it would be great to note this commit, that i can test the patch and eventually apply it in gentoo! :)

Thanks for your time and work!

[mheiskan]

See also https://kb.meinbergglobal.com/kb/time_sync/ntp/configuration/ntp_leap_second_file#the_leap_second_file_provided_by_the_olsoniana_tz_db

[HowardHinnant]

Ok, try tip-of-trunk master branch and let me know how it goes.

[JonasToth]

The tests to pass now. Both in the package environment as well as the manual reproduction with normal user settings.

Thank you for the fast fix!

Are you planning a new release (maybe 3.0.1) soon? It could very well be the case, that other linux distros suffer the same issue but don't know yet. It would include other fixes, too (like the cmake version bump). It would definitely make my life easier ;)

[HowardHinnant]

Ok, will do. Thanks for the nudge.

[fkobi]

if this is fixed can we close this issue @JonasToth @HowardHinnant?

[JonasToth]

I believe it is, yes.