Re: [tz] Unexpected footer in Africa/Casablanca
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.
Thanks for the quick fix, I appreciate it. Things are complicated with negative DST and timestamps past 2038. There are several APIs we support - java.util, java.time, ICU and native (Android's libc implementation). We try to keep these APIs consistent. libc and java.time should handle negative DST fine, but java.util as of now expects it to be positive <https://github.com/openjdk/jdk/blob/3121898c33fa3cc5a049977f8677105a84c3e50c...>. ICU is also using rearguard format and AFAIK they have no plans to migrate off it. Currently we do not work on negative DST. Please also see Neil's answer <https://mm.icann.org/pipermail/tz/2021-June/030250.html>. Situation with 2038 is better - all Java code handles past 2038 timestamps properly on all platforms with java.util.TimeZone as the only exception - our implementation uses pregenerated transitions only. I am working on that now (hence my question about footer). libc on 32-bit platforms won't work properly, as time_t is 32-bit there and AFAIK there are no plans to fix that. 64-bit platforms are safe. If you have plans to deprecate rearguard format please let us know in advance. Preparation for it will take a while. Thanks, Almaz On Mon, 10 Jan 2022 at 20:46, Paul Eggert <eggert@cs.ucla.edu> wrote:
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.
Follow up question on footers: Using commands above I've noticed TZif files for some time zone (like America/Nuuk, Asia/Tel_Aviv, Pacific/Fiji) are generated in TZif3 format. I believe it is due to their footers, which use TZ String Extensions [1] to achieve "day before" semantics. Is there a way to force TZif2 format for all time zones? [1] https://datatracker.ietf.org/doc/html/rfc8536#section-3.3.1 On Tue, 11 Jan 2022 at 11:33, Almaz Mingaleev <mingaleev@google.com> wrote:
Thanks for the quick fix, I appreciate it.
Things are complicated with negative DST and timestamps past 2038. There are several APIs we support - java.util, java.time, ICU and native (Android's libc implementation). We try to keep these APIs consistent. libc and java.time should handle negative DST fine, but java.util as of now expects it to be positive <https://github.com/openjdk/jdk/blob/3121898c33fa3cc5a049977f8677105a84c3e50c...>. ICU is also using rearguard format and AFAIK they have no plans to migrate off it. Currently we do not work on negative DST. Please also see Neil's answer <https://mm.icann.org/pipermail/tz/2021-June/030250.html>. Situation with 2038 is better - all Java code handles past 2038 timestamps properly on all platforms with java.util.TimeZone as the only exception - our implementation uses pregenerated transitions only. I am working on that now (hence my question about footer). libc on 32-bit platforms won't work properly, as time_t is 32-bit there and AFAIK there are no plans to fix that. 64-bit platforms are safe.
If you have plans to deprecate rearguard format please let us know in advance. Preparation for it will take a while.
Thanks, Almaz
On Mon, 10 Jan 2022 at 20:46, Paul Eggert <eggert@cs.ucla.edu> wrote:
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.
On 1/25/22 08:45, Almaz Mingaleev wrote:
Is there a way to force TZif2 format for all time zones?
No. I suppose someone could add a '-V N' option to to zic to refuse to generate anything past TZif format N, for whatever value of value of N you like. For the case you describe, zic would generate an empty footer (thus refusing to predict the future) since no version-2-format footer would be accurate for a future that requires version 3. However, I hope it isn't worth the trouble to write code like that. Any TZif parser that wasn't written to grok TZif format 3 should be doing something reasonable with format-3 TZ strings anyway - and if it isn't, I'd like to know the details before proceeding along the lines outlined above. Similar thoughts apply to TZif version 2 or 3 versus version 4, which should be in the next TZif RFC; see <https://datatracker.ietf.org/doc/draft-murchison-rfc8536bis/>.
participants (2)
-
Almaz Mingaleev -
Paul Eggert