<div dir="ltr"><div><div><font face="arial, sans-serif">Hi Paul - If it's OK, could I ask a few follow-ups?</font></div><br class="gmail-Apple-interchange-newline"></div><div><font color="#674ea7"><font face="monospace">> </font>They're not equivalent to any other Zones.</font></div><div style=""><br></div><div style=""><font face="arial, sans-serif">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.</font></div><blockquote style="margin:0 0 0 40px;border:none;padding:0px"><div style=""><font style="" face="arial, sans-serif"><br></font></div><font face="monospace"># Zone   NAME    STDOFF  RULES   FORMAT  [UNTIL]<br></font><font face="monospace">Zone     EST      -5:00  -       EST<br></font><font face="monospace">Zone     MST      -7:00  -       MST<br></font><font face="monospace">Zone     HST     -10:00  -       HST</font></blockquote><div><font face="monospace"><br></font></div><div><font face="arial, sans-serif">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. </font></div><blockquote style="margin:0 0 0 40px;border:none;padding:0px"><div><font face="monospace"><br></font></div><div><font face="monospace">Zone America/New_York   -4:56:02 -      LMT     1883 Nov 18 17:00u</font></div><div><font face="monospace">                   -5:00   US      E%sT    1920</font></div><div><font face="monospace">                 -5:00   NYC     E%sT    1942</font></div><div><font face="monospace">                 -5:00   US      E%sT    1946</font></div><div><font face="monospace">                 -5:00   NYC     E%sT    1967</font></div><div><font face="monospace">                 -5:00   US      E%sT</font></div></blockquote><div><br></div><div>EST5EDT has also used the same offset, rules, and format since 1967:</div><div><br></div><blockquote style="margin:0 0 0 40px;border:none;padding:0px"><div><font face="monospace">Zone EST5EDT -5:00 US E%sT</font></div></blockquote><div><br></div><div>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.</div><div><div><br></div><div>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?</div></div><div><br></div><div><font color="#674ea7">> How about limiting the enumeration to Zone names mentioned in</font></div><font color="#674ea7">> zone1970.tab? That would exclude the troublesome names.</font><div><br></div><div>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.</div><div><br></div><div>Thanks,</div><div>Justin</div><div><br></div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, May 21, 2024 at 8:08 PM Paul Eggert <<a href="mailto:eggert@cs.ucla.edu">eggert@cs.ucla.edu</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 2024-05-21 18:22, Justin Grant via tz wrote:<br>
> What was special about the Zones below that<br>
> caused them to stay as Zones?<br>
> <br>
> EST ...<br>
<br>
They're not equivalent to any other Zones.<br>
<br>
> EST => Etc/GMT+5<br>
<br>
For example, on the Ubuntu 23.10 machine I'm typing this email on:<br>
<br>
   $ TZ=EST date; TZ=Etc/GMT+5 date<br>
   Tue May 21 22:03:40 EST 2024<br>
   Tue May 21 22:03:40 -05 2024<br>
<br>
<br>
> ECMAScript's time zone enumeration API is specified to<br>
> only return Zone names, but ECMAScript implementations in Safari and Chrome<br>
> have long omitted the Zones above from their enumeration API because they<br>
> create redundant and confusing results for end users. We'd like to align<br>
> the specification to web reality, and ideally make these changes upstream<br>
> in TZDB (if that would be welcome).<br>
<br>
How about limiting the enumeration to Zone names mentioned in <br>
zone1970.tab? That would exclude the troublesome names.<br>
</blockquote></div>