Hi Paul - If it's OK, could I ask a few follow-ups?

> They're not equivalent to any other Zones.

For EST it seems that the offset and (lack of) rules are identical to Etc/GMT+5. The "Format" column is different. Is that the reason why EST is not a Link? If so, that's good to understand, because I'd previously assumed that if offset and rules were identical then zones might be candidates for merging.

# Zone   NAME    STDOFF  RULES   FORMAT  [UNTIL]
Zone     EST      -5:00  -       EST
Zone     MST      -7:00  -       MST
Zone     HST     -10:00  -       HST

Here's another case that's even more similar: America/New_York has used the US rules, -05:00 offset, and E%sT format since 1967. 

Zone America/New_York -4:56:02 - LMT 1883 Nov 18 17:00u
-5:00 US E%sT 1920
-5:00 NYC E%sT 1942
-5:00 US E%sT 1946
-5:00 NYC E%sT 1967
-5:00 US E%sT

EST5EDT has also used the same offset, rules, and format since 1967:

Zone EST5EDT -5:00 US E%sT

The same seems true for CST6CDT => America/Chicago, MST7MDT => America/Denver, and PST8PDT => America/Los_Angeles. Each pair has (I think?) had the same offset, rules, and format since before 1970.

Am I interpreting these Zone sections correctly? If so, then if the criteria for merging Zones (like Atlantic/Reykjavik and Africa/Abidjan) is that they've been the same since 1970, why isn't EST5EDT a Link to America/New_York, CST6CDT to America/Chicago, MST7MDT to America/Denver, and PST8PDT to America/Los_Angeles?

> How about limiting the enumeration to Zone names mentioned in
> zone1970.tab? That would exclude the troublesome names.

Yep, this is a good suggestion. It may be easier for us to just special-case the 11 legacy Zone names because most ECMAScript engines consume TZDB indirectly through ICU so we don't necessarily have easy access to zone1970.tab without adding new build-time dependencies. Given that no more legacy Zones are being created, special-casing may be easier for ECMAScript implementers. But we are still interested in seeing if least some of these 11 Zones could be merged upstream in TZDB, if only to reduce divergence between ECMAScript implementations and other users of TZDB.

Thanks,
Justin



On Tue, May 21, 2024 at 8:08 PM Paul Eggert <eggert@cs.ucla.edu> wrote:
On 2024-05-21 18:22, Justin Grant via tz wrote:
> What was special about the Zones below that
> caused them to stay as Zones?
>
> EST ...

They're not equivalent to any other Zones.

> EST => Etc/GMT+5

For example, on the Ubuntu 23.10 machine I'm typing this email on:

   $ TZ=EST date; TZ=Etc/GMT+5 date
   Tue May 21 22:03:40 EST 2024
   Tue May 21 22:03:40 -05 2024


> ECMAScript's time zone enumeration API is specified to
> only return Zone names, but ECMAScript implementations in Safari and Chrome
> have long omitted the Zones above from their enumeration API because they
> create redundant and confusing results for end users. We'd like to align
> the specification to web reality, and ideally make these changes upstream
> in TZDB (if that would be welcome).

How about limiting the enumeration to Zone names mentioned in
zone1970.tab? That would exclude the troublesome names.