Update UTC time zone canonicalization to match proposal-canonical-tz

[ptomato]

The test for tc39/ecma402#724 (added in #4328) didn't take the Time Zone Canonicalization proposal into account; but it should, because that proposal is stage 3.

As of that proposal, the [[TimeZone]] slot of DateTimeFormat gets the case-regularized original identifier, no longer the primary identifier. So the resolvedOptions().timeZone property also no longer returns the primary identifier.

[ptomato]

cc @ben-allen @justingrant

[anba]

Related open issues:

• Should identifiers that resolve to UTC always be canonicalized? proposal-canonical-tz#21
• Should DTF.p.resolvedOptions().timeZone canonicalize or not? proposal-canonical-tz#2

[justingrant]

This seems fine, but should this test be relocated out of the test/intl402/DateTimeFormat/ folder into a Temporal-specific folder?

Alternatively, maybe this test should both be copied into a Temporal folder, AND have a test remain here that instead of validating that DataTimeFormat canonicalizes zone IDs (current behavior) the test should validate that it's not canonicalized (new behavior)? Note that V8 is not planning to change the canonicalization behavior of DateTimeFormat until Temporal Stage 4, so it may be premature to land a DTF non-canonical change now.

[ptomato]

Alternatively, maybe this test should both be copied into a Temporal folder, AND have a test remain here that instead of validating that DataTimeFormat canonicalizes zone IDs (current behavior) the test should validate that it's not canonicalized (new behavior)?

I like that suggestion and I've adopted it now.

Note that V8 is not planning to change the canonicalization behavior of DateTimeFormat until Temporal Stage 4, so it may be premature to land a DTF non-canonical change now.

Things that are stage 3 are generally cleared to land in test262. Especially now that we have a canonical-tz feature tag, which I've added to these tests, V8 can just filter out results with that feature tag if they choose to implement canonical-tz later.

[gibson042]

LGTM. I suggested some syntax tweaks and assertion strengthening. I also wonder if we should replace const syntax with var and for (const timeZone of utcIdentifiers) { … } syntax with for (var i = 0; i < utcIdentifiers.length; i++) { var timeZone = utcIdentifiers[i]; … }, but that might be too extreme (though I suspect @ljharb may also be in favor of it).

[ljharb]

I’m in favor of it, but our policy is to not put undue burden on PR authors by requesting those changes, and instead to change them in future PRs.

[ptomato]

I've gone ahead and made the ES5 changes as well, it's a tiny PR so why not