Deprecating POSIX Zones to Links?
Hi TZ friends - I'm one of the volunteers working on ECMAScript's time zone strategy. We had a question: of all the legacy Zone names in TZDB, why have a few of them like "WET" and "EST5EDT" been retained as Zones, while the rest of the legacy names like "GB-Eire" and "Jamaica" have all been turned into Links pointing to some other Zone? What was special about the Zones below that caused them to stay as Zones? EST MST HST EST5EDT CST6CDT MST7MDT PST8PDT WET CET MET EET Regardless of the history behind these 11 Zone names, would there be interest in accepting a PR that turns these Zones into Links? I'm asking because 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). Here's the mappings that we're currently considering in ECMAScript. We used the TZ approach of preferring the largest city for each of the DST-using legacy Zones. Although any other mappings would be OK with us, so let me know if you think there are more appropriate mappings. EST => Etc/GMT+5 MST => Etc/GMT+7 HST => Etc/GMT+10 EST5EDT => America/New_York CST6CDT => America/Chicago MST7MDT => America/Denver PST8PDT => America/Los_Angeles WET => Europe/Lisbon CET => Europe/Berlin MET => Europe/Berlin EET => Europe/Kyiv Thanks, Justin Grant
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.
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.
I’m wondering if these legacy zones can be moved from northamerica / europe files to backward. I’m not sure about the background why ECMA folks require these zones supported in their spec, but one of the reasons why time zone database adopters try to support these legacy zones (EST5EDT, CST6CDT…) as same as modern/practical zones (America/New_York, America/Chicago..) is that these zones are in same zoneinfo files. My understanding is that these zones are included in the time zone database for backward compatibility purpose. I don’t know if there are any time zone database users still requiring these artificial zones. If these are moved to “backward” file, it would be clear for time zone database consumers that these are there for backward compatibility reasons. I also understand what Justin is willing to achieve. Historical zone offsets since 1970 are identical between EST5EDT and America/New_York. For some time zone adaptors, it would be nice if they can reduce number of unique zones. But, there might be still some time zone database users who want EST5EDT defined separately from America/New_York. For these reasons, I propose - 1) Move these legacy zones to “backzone” with keeping the current definition. 2) Also add them in “backward” file, but change EST5EDT and others as “Link” of modern zone sharing same historic offsets. Yoshito Umaoka
On 2024-05-22 08:32, Yoshito Umaoka wrote:
I propose -
1) Move these legacy zones to “backzone” with keeping the current definition. 2) Also add them in “backward” file, but change EST5EDT and others as “Link” of modern zone sharing same historic offsets.
Thanks, good suggestions. I installed the attached patches into the development repository on GitHub to attempt to implement them; please give the patches a try.
Thanks Paul! Your changes look good to me. This will save a bunch of people downstream a lot of time to avoid special-casing these legacy names. Thanks again, Justin On Wed, May 22, 2024 at 2:32 PM Paul Eggert <eggert@cs.ucla.edu> wrote:
On 2024-05-22 08:32, Yoshito Umaoka wrote:
I propose -
1) Move these legacy zones to “backzone” with keeping the current definition. 2) Also add them in “backward” file, but change EST5EDT and others as “Link” of modern zone sharing same historic offsets.
Thanks, good suggestions. I installed the attached patches into the development repository on GitHub to attempt to implement them; please give the patches a try.
participants (3)
-
Justin Grant -
Paul Eggert -
Yoshito Umaoka