@ptomato Stage 3 review

[justingrant]

This is a tracking issue for @ptomato to review the Time Zone Canonicalization proposal spec at https://tc39.es/proposal-canonical-tz/#sec-canonical-tz-intro.

The spec text is easiest to review as a web page rather than the raw spec text, because most of the text is just existing AOs with only one line changed. The total scope of changes is <20 lines + one prose paragraph.

[ptomato]

• I don't see any issues with the spec text, nice work!
• Re. https://tc39.es/proposal-canonical-tz/#sec-temporal-initializedatetimeformat - I agree with this change because it makes ECMAScript more inclusive of developers living in cities with decolonized names such as Kyiv, Kolkata, Nuuk, etc. However, during stage 3 we should ask implementations to be watchful for web compatibility issues in this particular change.
• There are several open issues that affect behaviour of the proposal (such as How to handle merging of intra-country Zones in TZDB? #9, Canonical IANA time zone name for Windows time zones #16). When presenting for stage 3, are you planning to close those issues and keep the current semantics of the proposal?
• In particular I'd like to see Canonical IANA time zone name for Windows time zones #16 resolved before stage 3 (even if the resolution is "change nothing, because the assertion in SystemTimeZoneIdentifier constrains what implementations can do here")
• Does the open issue about the waiting period (Implementer feedback about waiting period for renamed identifiers like Europe/Kiev=>Europe/Kyiv #17) affect anything in stage 3? I expect not, since the answer comes from implementation experience, but I think resolving this is a requirement for stage 4. Can we remove the TODO in the spec text and just keep the issue open?
• No concern for stage 3 either way, just letting you know in case you hadn't noticed - the links to ToTemporalTimeZoneIdentifier are broken, they go to https://tc39.es/proposal-temporal/#sec-totemporaltimezoneidentifier but should go to https://tc39.es/proposal-temporal/#sec-temporal-totemporaltimezoneidentifier

This is a positive review assuming the open issues that affect behaviour will be closed.

[justingrant]

Thanks Philip!

• Re. https://tc39.es/proposal-canonical-tz/#sec-temporal-initializedatetimeformat - I agree with this change because it makes ECMAScript more inclusive of developers living in cities with decolonized names such as Kyiv, Kolkata, Nuuk, etc. However, during stage 3 we should ask implementations to be watchful for web compatibility issues in this particular change.

Agreed

• There are several open issues that affect behaviour of the proposal (such as How to handle merging of intra-country Zones in TZDB? #9, Canonical IANA time zone name for Windows time zones #16). When presenting for stage 3, are you planning to close those issues and keep the current semantics of the proposal?

There's one more TG2 meeting before the next plenary where I'll try to get consensus one more time on open issues in advance of the next TC39 plenary.

The most urgent changes in this proposal are the normative changes to stop canonicalizing before storing internal slots, and the new TimeZone.p.equals method. Anything else can be handled in later normative or editorial PRs. So my plan is to lock the normative scope of this proposal at the next plenary if the proposal is approved for Stage 3.

I'm not sure it makes sense to close the issues just yet, because if we do get implementer consensus during Stage 3 then I'd be open to editorial text in this proposal (e.g. "implementations are recommended to...") to reify that consensus, and it's helpful to have a honeypot location for those discussions. But I'm also OK to to migrate those issues to the 402 repo if that's better. Let me know what you'd prefer.

If we do leave those issues open in the proposal, then we'll mark them with a label and title showing that only editorial changes will be made in this proposal's text (e.g. recommendations for implementers), not anything normative.

• In particular I'd like to see Canonical IANA time zone name for Windows time zones #16 resolved before stage 3 (even if the resolution is "change nothing, because the assertion in SystemTimeZoneIdentifier constrains what implementations can do here")

The resolution of this issue seems unlikely to happen soon, and also unlikely to yield anything other than an editorial note in the SystemTimeZoneIdentifier spec text (e.g. "Many implementations rely on a mapping layer between the host environment's time zone and the IANA Time Zone Database. These implementations are recommended to..."). Note that this encompasses not just Windows zones, but also ICU behavior which overrides what the OS says.

This is a good example of an issue that can be ported to 402 either before or during Stage 3 if we can't get implementer consensus on good text. It should not block this proposal moving fwd.

• Does the open issue about the waiting period (Concerns with waiting period for identifier renames #17) affect anything in stage 3? I expect not, since the answer comes from implementation experience, but I think resolving this is a requirement for stage 4. Can we remove the TODO in the spec text and just keep the issue open?

Nope. I'll remove the TODO. Should I add an editorial note pointing people at the open issue?

• links to ToTemporalTimeZoneIdentifier are broken, they go to https://tc39.es/proposal-temporal/#sec-totemporaltimezoneidentifier but should go to https://tc39.es/proposal-temporal/#sec-temporal-totemporaltimezoneidentifier

Thanks, will fix.

This is a positive review assuming the open issues that affect behaviour will be closed.

🎉

[ptomato]

OK, notes to reify the consensus sounds good to me. I'll assume the upcoming TG2 meeting will resolve most or all of these. If there's no signals from TG2 that any of these resolutions would result in significant changes, then I think it's fine to move forward.

[justingrant]

FYI: Temporal just merged an editorial PR to prepare for tc39/proposal-temporal#2607, which is the normative PR that limits offset time zones to minute precision.

As a result, today a few links in the proposal-canonical-tz spec text were broken, and a few lines of the proposal spec needed updating. I just landed a PR that catches up this proposal's spec and polyfill with those upstream changes. Apologies for the churn!

If you've already reviewed the rest of proposal-canonical-tz, please take a look at SystemTimeZoneIdentifier that has 2 changed lines + a new editor's note, and TimeZoneEquals that has 5 newly-changed lines.

AFAIK there are no more changes expected (either here or upstream) before the Bergen meeting.

[justingrant]

This proposal reached Stage 3 at the July 2023 TC39 meeting. As decided in the meeting, the next step is to merge this proposal into Temporal Stage 3 via tc39/proposal-temporal#2633. Thanks for the reviews and for your support of this proposal!