On 1/10/22 08:55, Almaz Mingaleev wrote:
I was investigating generated TZif files and the generated footer for Africa/Casablanca is "XXX-2<+01>-1,0/0,J365/23". Is that expected? Effectively it behaves like GMT+1, but SAVE is -1:00 even though it is 1:00 in rearguard.zi. How do I instruct zic to generate plain "<+01>-1" or skip it at all?
One fix is to change ziguard.awk to generate a rearguard-format .zi file that has a more-natural transition for Morocco in May 2087. ("More- natural" from the rearguard viewpoint that is; it's more-awkward from a real-world viewpoint.) Proposed patch attached; it causes the string to be "<+01>-1" for rearguard format too. Thanks for reporting the glitch.
I believe I am doing something wrong, as in MacOs it is empty and "<+01>-1" in Linux, but I can't figure out what command options I should specify in zic.
It's "<+01>-1" on GNU/Linux platforms like Ubuntu and Fedora that use the default format. These distros are not using rearguard-format TZif files and so don't have rearguard issues there. I'm not sure why it's empty in macOS. macOS 12.1's 'zic --version' reports "zic: @(#)zic.c 8.22" which corresponds to tzcode2010m, so perhaps it's merely because macOS is stuck on a tzcode version that is so old that you can't easily tell that macOS is using rearguard format. (macOS's zdump doesn't seem to work past the year 2038, and Apple should upgrade well before that year rolls around.) While we're on the subject, what is Android's current state of support for negative DST and for timestamps past 2038? On the GNU/Linux side, I expect most distros support both - the stragglers being old-fashioned 32-bit x86 and ARM distros, where 64-bit timestamps weren't supported until Linux 5.6 (2020-03-29) and glibc 2.34 (2021-08-02), and even now many apps haven't been updated yet.