Editorial: name = TimeZoneBracketedName <= TimeZoneIANAName

[FrankYFTang]

Change the definition of name in ParseTemporalTimeZoneString
from TimeZoneIANAName to TimeZoneBracketedName

Without this change, the assertion mententioned in #1924 will fail and therefore is not implementable and the tests mentioned in tc39/test262#3319 will also fail

Fix #1924

@ptomato @pdunkel @ljharb @justingrant @ryzokuken

[codecov]

Codecov Report

Merging #1941 (d3934c8) into main (6224630) will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##             main    #1941   +/-   ##
=======================================
  Coverage   95.01%   95.01%           
=======================================
  Files          19       19           
  Lines       10940    10940           
  Branches     1732     1732           
=======================================
  Hits        10395    10395           
  Misses        530      530           
  Partials       15       15           

Flag	Coverage Δ
test262	81.79% <ø> (ø)
tests	89.85% <ø> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 6224630...d3934c8. Read the comment docs.

[FrankYFTang]

This PR is not good enough. if name is defined as TimeZoneBracketedName step 7a of ParseTemporalTimeZoneString will throw if name is NOT TimeZoneIANAName

a. If ! IsValidTimeZoneName(name) is false, throw a RangeError exception.

[gibson042]

This change does not look correct to me; I don't think ParseTemporalTimeZoneString input like "2021-12-28T17:42:00Z[-05:00]" (which includes TimeZoneBracketedName but not TimeZoneIANAName) should result in a record with nonempty [[Name]] or input like "2021-12-28T17:42:00+00:00[-05:00]" (likewise) should be rejected when "-05:00" does not pass the IsValidTimeZoneName check.

[FrankYFTang]

@gibson042 could you take a look at tc39/test262#3319 and give your opinion there? I have no strong opinion about this PR . I propose it because @ptomato said it is a spec bug not a bug in the tests. But I am pretty sure this PR in the current shape fix the problem.

[ptomato]

Well, a [[Name]] containing an offset string cannot be passed to IsValidTimeZoneName, so if we make this change, we will have to check for that possibility down below. But I think it is correct that 2021-12-28T17:42:00Z[-05:00] should result in { [[Z]]: true, [[OffsetString]]: undefined, [[Name]]: "-05:00" }. That seems to be what ParseTemporalZonedDateTimeString expects.

Re. the former fix, it may be easier if you implement this on top of #1953.

[jessealama]

FYI #2050 (currently also a draft)

[ptomato]

@FrankYFTang Is this problem still occuring after the fix in #2050?

[IdanHo]

@FrankYFTang Is this problem still occuring after the fix in #2050?

It is still occurring, TimeZoneBracketedName still has 2 alternatives, TimeZoneIANAName and TimeZoneUTCOffsetName and in the case of the second one the assertion fails. (Example test262 test the fails the assertion: https://github.com/tc39/test262/blob/main/test/built-ins/Temporal/ZonedDateTime/from/zoneddatetime-string.js#L18)

[ptomato]

This part was refactored enough in #2050 that it's probably easier to start over, I've done this in #2200.