HowardHinnant
commented
1 year ago Your analysis is correct. This library ignores the posix time zone string. Although this is a known bug, it was first introduced accidentally.
I have not had time to devote to fixing it. But I would consider a patch to do so.
The priority on this issue is low since users are encouraged to migrate away from this library and to C++20 chrono, especially by the time the "fat" installation ends its explicit transitions. The last bits of C++20 were pushed onto the gcc trunk just last Saturday. This is already available for experimentation on godbolt with the "gcc trunk" option.
This library is known to not operate properly with the "slim" option.
Hi,
First of all, thank you very much @HowardHinnant for the development and continued support to the date and tz libraries.
I am trying to use these libraries on Linux with USE_OS_TZDB set to 1 in order to use the tzfiles embedded in the Linux distribution and typically located in /usr/share/zoneinfo. These tzfiles (https://man7.org/linux/man-pages/man5/tzfile.5.html) contain - among other things - a list of explicit transitions describing when and how the time zone offset changes over time. They also contain at the end a “TZ string” (https://www.di-mgt.com.au/wclock/help/wclo_tzexplain.html) that describes the daylight saving adjustments to be applied to instants after the last explicit transition.
After experiencing an issue on a Yocto-based system, I realized the tz library properly loads the explicit list of transitions but does not consider the “TZ string”. The consequence is conversions between time zones do not properly take into account daylight saving for any timepoint after the last explicit transition. For the Europe/Paris time zone I used for testing, the last explicit transition is:
Technically, these two definitions are the equivalent because the same TZ string “CET-1CEST,M3.5.0,M10.5.0/3” is applicable since March 1996. It seems the difference comes from the tzfiles are generated by zic with the slim option for the Yocto-based system (probably for minimal footprint) and with the fat option for the Ubuntu system (probably for maximal compatibility).
Could you please confirm I am not mistaken with the tz library behavior? Has the “TZ string” been intentionally ignored when the feature has been implemented? If yes, could you explain why? If no, do you think it would be a relevant fix/addition to the library?
Thank you for your assistance.