<div dir="ltr">Follow up question on footers:<div>Using commands above I've noticed TZif files for some time zone</div><div>(like America/Nuuk, Asia/Tel_Aviv, Pacific/Fiji) are generated in TZif3 format.</div><div>I believe it is due to their footers, which use TZ String Extensions [1] to</div><div>achieve "day before" semantics. </div><div>Is there a way to force TZif2 format for all time zones? </div><div><br></div><div>[1] <a href="https://datatracker.ietf.org/doc/html/rfc8536#section-3.3.1">https://datatracker.ietf.org/doc/html/rfc8536#section-3.3.1</a></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, 11 Jan 2022 at 11:33, Almaz Mingaleev <<a href="mailto:mingaleev@google.com" target="_blank">mingaleev@google.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Thanks for the quick fix, I appreciate it.<div><br></div><div>Things are complicated with negative DST and timestamps past 2038.</div><div>There are several APIs we support - java.util, java.time, ICU</div><div>and native (Android's libc implementation). We try to keep these APIs</div><div>consistent.</div><div>libc and java.time should handle negative DST fine, but java.util as of</div><div>now expects <a href="https://github.com/openjdk/jdk/blob/3121898c33fa3cc5a049977f8677105a84c3e50c/src/java.base/share/classes/java/util/SimpleTimeZone.java#L352" target="_blank">it to be positive</a>. ICU is also using rearguard format and</div><div>AFAIK they have no plans to migrate off it. Currently we do not work</div><div>on negative DST. Please also see <a href="https://mm.icann.org/pipermail/tz/2021-June/030250.html" target="_blank">Neil's answer</a>. </div><div>Situation with 2038 is better - all Java code handles past 2038 timestamps</div><div>properly on all platforms with java.util.TimeZone as the only exception -</div><div>our implementation uses pregenerated transitions only. I am working on</div><div>that now (hence my question about footer).</div><div>libc on 32-bit platforms won't work properly, as time_t is 32-bit there and</div><div>AFAIK there are no plans to fix that. 64-bit platforms are safe.</div><div><br></div><div>If you have plans to deprecate rearguard format please let us know in</div><div>advance. Preparation for it will take a while.</div><div><br></div><div>Thanks,</div><div>Almaz</div><div><div><br></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, 10 Jan 2022 at 20:46, Paul Eggert <<a href="mailto:eggert@cs.ucla.edu" target="_blank">eggert@cs.ucla.edu</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 1/10/22 08:55, Almaz Mingaleev wrote:<br>
<br>
> I was investigating generated TZif files and the generated footer for <br>
> Africa/Casablanca is "XXX-2<+01>-1,0/0,J365/23". Is that expected?<br>
> Effectively it behaves like GMT+1, but SAVE is -1:00 even though it is <br>
> 1:00 in rearguard.zi. How do I instruct zic to generate plain "<+01>-1" <br>
> or skip it at all?<br>
<br>
One fix is to change ziguard.awk to generate a rearguard-format .zi file <br>
that has a more-natural transition for Morocco in May 2087. ("More- <br>
natural" from the rearguard viewpoint that is; it's more-awkward from a <br>
real-world viewpoint.) Proposed patch attached; it causes the string to <br>
be "<+01>-1" for rearguard format too. Thanks for reporting the glitch.<br>
<br>
<br>
> I believe I am doing something wrong, as in MacOs it is empty and <br>
> "<+01>-1" in Linux, but I can't figure out what command options I should <br>
> specify in zic.<br>
<br>
It's "<+01>-1" on GNU/Linux platforms like Ubuntu and Fedora that use <br>
the default format. These distros are not using rearguard-format TZif <br>
files and so don't have rearguard issues there.<br>
<br>
I'm not sure why it's empty in macOS. macOS 12.1's 'zic --version' <br>
reports "zic: @(#)zic.c 8.22" which corresponds to tzcode2010m, so <br>
perhaps it's merely because macOS is stuck on a tzcode version that is <br>
so old that you can't easily tell that macOS is using rearguard format. <br>
(macOS's zdump doesn't seem to work past the year 2038, and Apple should <br>
upgrade well before that year rolls around.)<br>
<br>
While we're on the subject, what is Android's current state of support <br>
for negative DST and for timestamps past 2038? On the GNU/Linux side, I <br>
expect most distros support both - the stragglers being old-fashioned <br>
32-bit x86 and ARM distros, where 64-bit timestamps weren't supported <br>
until Linux 5.6 (2020-03-29) and glibc 2.34 (2021-08-02), and even now <br>
many apps haven't been updated yet.</blockquote></div>
</blockquote></div>