[tz] Unexpected footer in Africa/Casablanca

Almaz Mingaleev mingaleev at google.com
Tue Jan 11 11:33:08 UTC 2022


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: <https://mm.icann.org/pipermail/tz/attachments/20220111/fb1cf667/attachment-0001.html>


More information about the tz mailing list