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

Jonathan Wakely jwakely at redhat.com
Tue Apr 30 20:38:37 UTC 2024


On Tue, 30 Apr 2024 at 19:57, Brian Inglis via tz <tz at iana.org> wrote:
>
> On 2024-04-30 06:46, Jonathan Wakely via tz wrote:
> > Given this snippet from tzdata.zi:
> >
> > Z Australia/Sydney 10:4:52 - LMT 1895 F
> >    10 AU AE%sT 1971
> > R AU 1917 o - Ja 1 2s 1 D
> > R AU 1917 o - Mar lastSu 2s 0 S
> > R AU 1942 o - Ja 1 2s 1 D
> > R AU 1942 o - Mar lastSu 2s 0 S
> > R AU 1942 o - S 27 2s 1 D
> > R AU 1943 1944 - Mar lastSu 2s 0 S
> > R AU 1943 o - O 3 2s 1 D
> >
> > What should the abbreviation be for the zone in, say, 1900?
> >
> > Using glibc I get AEST:
> >
> > TZ=Australia/Sydney date --date="1900-01-01"
> > Mon 1 Jan 00:00:00 AEST 1900
> >
> > But I don't see any way to get "AEST" from the tzdata and the spec in
> > the zic(8) man page.
> >
> > Prior to 1895 it is "LMT", and then from 1917-01-01 it's "AEDT", and
> > from 1917-03-25 it's "AEST", but none of the Rule lines apply to dates
> > before 1917, so what value of LETTER/S should be used for the AE%sT
> > format in 1900?
> >
> > Glibc solves this by iterating through all the transitions for the AU
> > rule until it finds a valid name for a transition to DST and a valid
> > name for a transition out of DST, and then remembers those two names,
> > which in this case gives AEDT (from 1917-01-01 to 1917-03-25) and AEST
> > (from 1917-03-25 to 1942-01-01). Then when it finds the info for a
> > date in 1900 it looks at the isdst field of struct tm for that date,
> > and picks one of the two remembered names, which gives us "AEST". That
> > seems like the correct result, but nothing in the zic man page (or any
> > other docs I can find) says that is what's supposed to happen.
> >
> > My code for GCC's C++ library is an independent implementation based
> > on the spec, and it has no way to produce "AEST" for 1900.
> >
> > It seems to me that either the spec should to do ... something ... so
> > that a LETTER/S field for the Rule can be found, or there should be a
> > Zone continuation line in the tzdata that explicitly says that
> > Australia/Sydney is always on standard time for the period 1895-02-01
> > to 1917-01-01 and that the abbreviation is AEST (without any %s that
> > needs to be expanded). So add the second line here:
> >
> > Z Australia/Sydney 10:4:52 - LMT 1895 F
> >    10 - AEST 1917
> >    10 AU AE%sT 1971
> > R AU 1917 o - Ja 1 2s 1 D
> > R AU 1917 o - Mar lastSu 2s 0 S
> > R AU 1942 o - Ja 1 2s 1 D
> > R AU 1942 o - Mar lastSu 2s 0 S
> > R AU 1942 o - S 27 2s 1 D
> > R AU 1943 1944 - Mar lastSu 2s 0 S
> > R AU 1943 o - O 3 2s 1 D
> >
> > I'm sure this question could also be asked of many other zones,
> > Australia/Sydney just happens to be the one I was testing with and
> > noticed that my code couldn't expand the %s in "AE%sT".
> >
> > Am I missing something that says to use "S" as the LETTER/S field for
> > dates prior to the first DST transition in 1917? What logic do other C
> > libraries use to get "AEST" here?
>
> It is default standard time LMT, STD, ... until it is not?

Yes, the question is not whether the zone uses STD or DST, I thought I
was clear I'm only talking about how to handle %s in a Zone's FORMAT.
I'm not asking "why did Australia/Sydney use STD before it started
using DST?" because that is self-explanatory.

The question is about what value of LETTER/S to use for the format
AE%sT in 1900. The %s should be replaced by the LETTER/S field of the
rule in effect at the time, but there is no AU rule that is in effect
prior to 1917. So how does AE%sT get expanded to AEST?

> You do not want to need rules for all the tropical (or polar) zones where there
> are no summer time changes.

Those zones don't use %s so the question doesn't arise. They don't
have transitions, so there's no variable part of their FORMAT fields.

> Read https://data.iana.org/time-zones/tz-how-to.html or
> /usr/share/doc/tzcode/tz-how-to.html then look at the zic code for defaulting
> time types, calculating tt_desigidx, and adding to tzh_charcnt as in tzfile(5).

The America/Chicago zone in the how-to doc has the same problem. After
1883 the zone uses the "US" rules, and the format is C%sT. So what is
the LETTER/S field for Chicago in 1900? Which of the "US" rules is in
effect in 1900 and so provides the LETTER/S field?

The how-to document even says this explicitly! "The last two make
sense only if there’s a named rule in effect." Where "the last two"
refers to using / or %s in a Zone's FORMAT field. But that document
also provides the answer:

"One wrinkle, not fully explained in zic.8.txt, is what happens when
switching to a named rule. To what values should the SAVE and LETTER
data be initialized? [...] If switching to a named rule before any
transition has happened, assume standard time (SAVE zero), and use the
LETTER data from the earliest transition with a SAVE of zero."

And that matches what glibc does: it finds the earliest transition
with SAVE of zero, and uses that LETTER for the period before the
first transition.

Should this "wrinkle" be documented in the zic(8) man page? Is there
some other source of truth documenting that behaviour, or is the
how-to document the only place?



More information about the tz mailing list