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. 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. 

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.