
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=41475399643... 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=41475399643...
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....)