Time after last transition from tzdata file is not correct

[MJLHThomassen-Sorama]

Hey there!

I'm using version 3.0.1 of date.h and tz.h.
I'm running my code on a NVidia Jetson device, installed with out own company yocto distro. This currently ships with version 2022a of the tzdata files.

Exact links used:
http://www.iana.org/time-zones/repository/releases/tzcode2022a.tar.gz
http://www.iana.org/time-zones/repository/releases/tzdata2022a.tar.gz

I'm trying to print the current date and time to a string from my location, with the device's locale set to Europe/Amsterdam (as of time of writing, this should result in "2022-11-30 15:28:00 +01:00" as daylight savings is not in effect currently here in the Netherlands)

I use the following code to achieve this on our device:

// Calculate UTC offset for current timestamp
auto zonedTime = date::make_zoned(date::current_zone(), std::chrono::system_clock::now()));

// System time to string
std::string s = date::format("%FT%T%Ez", zonedTime) ;

However, the string that is outputted is: "2022-11-30 16:28:00 +02:00", so, as if daylight savings was in effect (which it is not).

I've looked trough the code, and the timezone db file for Europe/Amsterdam has 97 transitions listed, with the last one being 1996-03-31 01:00:00. So everything after that date is regarded as being in +02:00 (daylight saving), which is incorrect.

I've perused the source code of tz.cpp but i can't seem to find the issue. I believe it has something to do with the tzfile format. The current version for the tzfile for Europe/Amsterdam on our device is version 2. According to the tzfile documentation (https://man7.org/linux/man-pages/man5/tzfile.5.html):

For version-2-format timezone files, the above header and data
are followed by a second header and data, identical in format
except that eight bytes are used for each transition time or leap
second time. (Leap second counts remain four bytes.) After the
second header and data comes a newline-enclosed, POSIX-TZ-
environment-variable-style string for use in handling instants
after the last transition time stored in the file or for all
instants if the file has no transitions.

I think the important bit is

After the
second header and data comes a newline-enclosed, POSIX-TZ-
environment-variable-style string for use in handling instants
after the last transition time stored in the file

I don't believe this is happening currently, and that is why i am getting wrong informations about dates after 1996. Can you confirm this?

If i parse the Europe/Amsterdam file with zdump and print out dates after 1996, it prints out all transitions correctly. Also my timedatectl status output shows the correct (non dst) timestamp and that one is also using the same file. Can you please assist with this?

[HowardHinnant]

In building your distro, does your process use the zic compiler to create the binary tz database?

There's a known bug in this library that it does not handle the zic -b slim option, which became the default in the past few years. Using zic -b fat fixes the problem. See also #614.

If that's not the issue, I can try again. By coincidence I have the binary database for 2022a installed on my macOS machine, and I'm getting the correct +01:00 offset.

[HowardHinnant]

You are correct that the tz.cpp binary parser does not handle the trailing posix tz string. However my understanding is that the v2 format doesn't use posix tz string until after 2038 (at which time this library should not have been used for a decade).

[MJLHThomassen-Sorama]

@HowardHinnant Thanks for the input. I would have to check what's going on there, we use the default "tzdata" recipe thats provided by yocto, so ill need to dig in and see which compiler settings, if any, are used (i just assumed the data was extracted from the tar.gz files and put on our rootfs). I'll get back to you on this.

As for the deprecation of this lib in favor of std::chrono, unfortunately, we have a bit of an issue there. We are working on an Nvidia Jetson Nano, the latest Nvidia CUDA SDK for the nano is a version which requires GCC 8 if you want to compile and link against the CUDA libraries from Nvidia. GCC 8 does not support C++ 20 yet (atleast, most of it not yet, we even had to struggle to get C++ 17 to work) :( So thats is why we are using date.h

[MJLHThomassen-Sorama]

Ah yes, i checked the yocto bitbake recipe for tzdat, the "zic -b slim" option is indeed used. Fortunately the creators made it settable, so ill try to set it to "fat" and try again.

[HowardHinnant]

This library will hang around for a decade or so, most likely with minimal to no maintenance. Fingers crossed on "fat"...

[MJLHThomassen-Sorama]

I have validated that compiling tzdata using the "fat" option solves the problem in my original post. You can close this issue (hopefully other people will find the information here useful).

For full clarity, in the yocto recipe for tzdata (poky/meta/recipes-extended/timezone/tzdata.bb) there is a variable ZIC_FMT, which defaults to "slim" (we are using dunfell branch, so depending on your yocto branch, this might differ). We also have our own distro file in our own layer that gets build when running bitbake. In this distro file, i have set ZIC_FMT = "fat". This compiles tzdata with the fat option which, on our device, now results in date/tz to include the correct utc offset, for, well, now as of the time of writing this post anyway, for the Europe/Amsterdam zone.

Thanks for the help @HowardHinnant ! Much apreciated.