[tz] Unexpected footer in Africa/Casablanca

Almaz Mingaleev mingaleev at google.com
Tue Jan 25 16:45:04 UTC 2022

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
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 at 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/src/java.base/share/classes/java/util/SimpleTimeZone.java#L352>.
> 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 at 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/tz/attachments/20220125/b0138cb1/attachment.htm>

More information about the tz mailing list