search

tc39 / proposal-canonical-tz

TC39 Proposal (stacked on Temporal) to improve handling of changes to the IANA Time Zone Database
Other
38 stars 2 forks source link

Implementer feedback about waiting period for renamed identifiers like Europe/Kiev=>Europe/Kyiv #17

Open justingrant opened 1 year ago

justingrant commented 1 year ago

In the May 2023 TC39 meeting, @dminor (Mozilla) brought up a concern around the proposed waiting period for renames.

The issue is that if there's a waiting period for renames, it introduces extra work for implementers because it turns renames from a one-release change (turn the old ID into a non-primary identifier, and add the new ID as primary) into a two-release change:

  1. Add the new ID as non-primary
  2. 2 years later, swap the primary status of the old and new IDs

Dan, did I represent your concern correctly?

One caveat is that renames are rare: once per year from 2020-2022, and no renames for 4 years before that. So there would be extra work here, but not a lot of extra work.

I'm not sure there's a compromise answer here: either evergreen ECMAScript implementations will give out IDs that remote systems may not recognize (because clients are usually updated faster than servers), or implementations would need to do some extra work to delay making newly-renamed IDs canonical.

For context, here's the spec text in question:

Although the IANA Time Zone Database maintainers strive for stability, in rare cases identifiers will be renamed. For example, the IANA Time Zone Database's 2022b release added "Europe/Kyiv" as a new Zone and demoted "Europe/Kiev" to be a Link to the new Zone. To reduce disruption from these renaming changes, ECMAScript implementations are encouraged to initially add the new name as a non-primary time zone identifier that resolves to the old primary identifier. Then, after a waiting period, implementations are recommended to promote the new Zone to a primary time zone identifier while simultaneously demoting the deprecated name to non-primary. The recommended waiting period is two years (TODO: may change) after the IANA Time Zone Database release containing the changes. This is long enough to allow most other systems that ECMAScript programs may interact with to "catch up" with the change so that the new zone is recognized. Note that this waiting period should only apply to cases where an existing Zone is replaced by a new Zone name. If an existing Zone and Link are swapped, then no waiting period is recommended.

dminor commented 1 year ago

Thanks for filing this, that captures my concern nicely :) I'd like to ask for feedback from @anba here, since he's currently handling these updates for us.

justingrant commented 1 year ago

@anba - do you have any feedback on this issue? Is a 2-year waiting period after renames (like 2022's Europe/Kiev=>Europe/Kyiv) OK with you?

The relevant spec text is the <emu-note> added in https://tc39.es/proposal-canonical-tz/#sup-time-zone-identifiers.

anba commented 1 year ago

I guess it's okay to add some sort of waiting period. Implementation-wise there are some issues I still have to think about, but those shouldn't matter for this proposal:

justingrant commented 1 year ago
  • Do we want to revert the Europe/Kyiv change in Firefox? (Probably not because we've already shipped the change.)

Agreed. For Firefox, I think the waiting period should start with the next rename. No need to make two additional breaking changes, because anyone already broken by Kyiv will have probably fixed or worked around the problem already.

  • Do we want to propagate renamed identifiers earlier to Firefox Nightly users or can we let renames ride the release train the usual way?

How do you normally handle rollout of changes that you're concerned might break some clients? How far in advance do you roll those changes into Nightly before they roll out to all clients?

My naive opinion: pushing changes out to Nightly immediately after IANA releases a rename would not be good, because it'd generate bug reports that will get fixed as servers upgrade to the latest Node release. It seems reasonable to give server apps at least 12-18 months to upgrade on their normal cadence before people start bothering them about time zones being out of date.

But getting renaming changes out to Nightly before the 2 year period expires might help early adopters file bugs against server apps that are slow to upgrade, before they get deluged with bugs from normal-release clients. Maybe 3 months earlier would be ideal?

If that's too much work, then "normal release train" is probably fine, and you can post-mortem after the next rename to see if you need more advance warning in Nightly.

That means ESR will use stable identifiers during the complete ESR support cycle and only when a new ESR version is released, renamed identifiers are used.

This sounds to me like a good plan. I suspect that enterprise users care more about stability than having the latest canonical ID.