[tz] Why is "AEST" the abbreviation for Australia/Sydney in 1900?

[Paul Eggert]

On 2024-05-02 01:10, Jonathan Wakely via tz wrote:

> I mean glibc code such as:
> https://sourceware.org/git/?p=glibc.git;a=blob;f=time/tzfile.c;h=41475399643913ac4eb78c7f84151692bc521984;hb=HEAD#l416
> The comment says it's finding the offsets, but it seems to be finding
> the abbreviations for the first two transitions, storing them in the
> __tzname array.

That code is present for a different reason. It's trying to support 
obsolescent (but POSIX-required) variables like tzname, which in general 
make no sense when TZif files are used. (The next POSIX draft tries to 
fix this, but it's messed up, and I haven't had time to interact with 
the POSIX committee to clean things up.)

These obsolescent compatibility variables are not related to the 
question of what is the proper abbreviation to use for timestamps in 1908.


> There's similar logic here:
> https://sourceware.org/git/?p=glibc.git;a=blob;f=time/tzfile.c;h=41475399643913ac4eb78c7f84151692bc521984;hb=HEAD#l596

This code is present for yet another different reason. In this area, 
glibc uses a heuristic in which it infers a time type before the first 
transition by looking for the first time type that uses standard time. 
This heuristic is related to (but differs from) a similar heuristic that 
was introduced to tzcode in 1986 and has evolved over the years to fix 
various issues with it. Unfortunately the heuristic has been so 
problematic (e.g., tzcode differs from glibc which surely differs from 
other TZif readers) that Internet RFC prohibits the practice, and says 
that TZif readers should simply use time type 0 for timestamps before 
the first transition.

The tzcode heuristic is present only for backwards compatibility to old 
(and now nonstandard) versions of zic. Now is a good time to fix tzcode, 
so that it conforms to Internet RFC 8536 in this area. I installed the 
attached proposed patch.

Glibc should also be fixed to conform to the RFC, but that is a separate 
matter.

Anyway to get back to your original email, as Florian mentioned this is 
not an issue about the TZif-reading code in glibc proper; it's an issue 
about zic, the TZif writer that glibc mererly copies from tzcode. Arthur 
wrote some email about that to clarify things, and I plan to follow up 
to his email.

Thanks for bringing this up, as it reminded me the time is ripe for the 
reference implementation to conform to the RFC in this area. (And sorry 
for the belated reply; things have been hectic around UCLA lately....)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Conform-to-RFC-8536-section-3.2-for-default-type.patch
Type: text/x-patch
Size: 5582 bytes
Desc: not available
URL: <https://mm.icann.org/pipermail/tz/attachments/20240502/995ede02/0001-Conform-to-RFC-8536-section-3.2-for-default-type.patch>