[tz] Deprecating POSIX Zones to Links?

[Justin Grant]

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 at 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.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mm.icann.org/pipermail/tz/attachments/20240522/a31dbe77/attachment-0001.html>