(catching up) Here's more context around IETF's reasoning, and more generally why restricting offset time zones to minutes seems OK to me:

Existing RFC3339 timestamp strings (which the new IETF spec, aka "IXDTF", extends) only support HH:MM in the offset, e.g. 2023-07-12T14:06-07:00. You can't use 07:00:01 or even 07:00:00 because parsers wouldn't recognize it. JS Date has the same same limit, BTW.

In the new IETF spec, they didn't want to change anything about the RFC3339 portion of the IXDTF timestamp, only the stuff in brackets after the timestamp is what's new. Otherwise, existing RFC3339 parsers would break for the before-brackets portion. Of course, that's not necessarily related to what's in brackets. We could have different precision for the in-brackets portion because there's no legacy.

But with IXDTF, the rule is that the RFC3339 offset must match the offset of the time zone in brackets. So 2020-01-01T00:00-05:00[America /Los_Angeles] is considered an error because the offset doesn't match the time zone.

For named time zones that have sub-minute precision, the new IETF spec handles it by being flexible about what "match" means: if the bracketed time zone's offset, when rounded to HH:MM, matches the offset in the RFC3339 portion of the string, then there's no error produced.

So 1970-01-01T00:00-00:45[Africa/Monrovia] is considered valid, even though Liberia's offset in 1970 was -00:44:30. The rounding hack simply tells the receiver not to throw an error in that case; it doesn't change the actual instant that the string represents. The instant described by "midnight on Jan 1 1970 in Liberia" is still 44:30 away from UNIX epoch:

Temporal.ZonedDateTime.from('1970-01-01T00:00-00:45[Africa/Monrovia]').toInstant();
// => 1970-01-01T00:44:30Z

Temporal does the same thing in reverse in ZonedDateTime.p.toString(): it formats the instant by rounding the offset to the nearest minute.

Anyway, that's how it works for named time zones. But what about offset time zones?

Because the offset in the RFC3339 portion of the string is constrained to HH:MM, the IETF folks felt that it'd be better to also limit the bracketed time zone to HH:MM too. There's nothing preventing us from extending the format in the future if there's customer demand, using the same rounding hack used for named time zones, so that 1970-01-01T00:00-00:45[-00:44:30] would also be allowed.

But it's not clear (to me at least) that this customer demand will ever materialize. Offset time zones were really only added to Temporal and IXDTF for backwards compatibility with Java. It's not clear how much usage of offset time zones there will be in Temporal. Partly this is because all IANA time zones today are on 15-minute boundaries. Sub-minute offsets haven't been official in any country since the 1970s, and even then it was rare. And offset time zones intentionally dispense with the main value of time zones in Temporal: the ability to automatically adjust timestamps for DST and other time zone weirdness.

Also, there's a storage advantage. If offset time zones are limited to minutes, then a Temporal.TimeZone can fit in a 16-bit union: 12 bits for offset time zones (±24h at minute-precision), 10 bits for the index into ~600 named time zones, and one bit to choose between them. Sub-minute offsets would require 50% more bytes to support a use case with questionable demand.

Finally, any user who really needs an offset time zone with sub-minute precision can create a custom time zone with granularity down to nanoseconds. Which they'd have to do anyways for time zones like TAI which don't have constant offsets (thanks leap seconds!) so you can't use an offset time zone anyways. AFAICT, there has never been a real-world time zone that has had a non-minute-aligned offset whose offset has never changed. So I'm kinda skeptical that "offset time zones at sub-minute precision" are real things.

P.S. - one concern raised was how RFC 5545 (aka iCalendar) supports second-precision offsets. But AFAICT, those offsets are never actually used for time zone identifiers. Rather, they're used to define the offsets of named time zones. And Temporal is already permissive with timestamp offset inputs, so we'll accept strings like 1970-01-01T00:00-00:44:30 which AFAICT is what RFC5545 needs.

Summary: restricting to minutes for built-in offset time zones seems like a safe initial bet that we can always extend later if needed.

Thanks for coming to my obscure TED talk.

There are two pieces required to fully solve this:

1. Stop canonicalizing user-inputted IDs to canonical IDs that are sometimes outdated and/or varying across browsers. By bringing proposal-canonical-tz to Stage 3 and merging it into Temporal, this problem gets solved as soon as Temporal.TimeZone ships in implementations. Yay!
2. Stop using outdated canonical IDs. Today this affects all IDs, but after (1) is done this will only affect IDs generated by ECMAScript itself, e.g. new Intl.DateTimeFormat().resolvedOptions().timeZone and Intl.supportedValuesOf('timeZone').

These two pieces are independent! Even though yesterday the committee agreed to hold (1) until Temporal.TimeZone ships, for (2) implementations are already free to return Europe/Kyiv, Asia/Kolkata, and Asia/Ho_Chi_Minh as canonical IDs. Firefox does this today, and Anba has argued (convincingly, IMO) that the FF behavior is more spec-compliant with current 402.

V8 and JSC don't do this today because they rely on CLDR and ICU which never update renamed IDs. But nothing stops ICU-using implementations from doing what Firefox does and overriding the ~20 zones in CLDR that use out-of-date names. If an ICU solution will take 2 years, could V8 and JSC in the meantime just add a hard-coded mapping table of 20 IDs? It's not like renames happen often: less than once per year is the average. If you, shu , and Frank wanted to do this badly enough, I suspect it could get done fast!

That said, it's a reasonable argument that doing (1) before (2), or at the same time, would reduce the negative impact to existing code because user-inputted zones wouldn't be affected.

My suggestion:

• Let's get implementations building & shipping Temporal! After this plenary's normative changes are merged within a week or two, AFAIK there are no other large changes on the horizon.
• IMO, V8 and JSC should really consider the 20-item hard-coded mapping table to work around CLDR's slow schedule. Could this work be paired with Temporal implementation instead of waiting until later? Could this work start now, and ship in a limited test to gauge the web-compat impact?

Let me know how I can help!

if the bracketed time zone's offset, when rounded to HH:MM, matches the offset in the RFC3339 portion of the string, then there's no error produced

justingrant I was wondering about how this rounding handled midpoint values like -00:44:30 or +00:44:30 (specifically "ties away from zero" vs. "ties toward positive infinity" vs. "ties toward even"), but I don't see any mention of it at https://www.ietf.org/archive/id/draft-ietf-sedate-datetime-extended-08.html or https://github.com/ietf-wg-sedate/draft-ietf-sedate-datetime-extended/blob/main/draft-ietf-sedate-datetime-extended.md . Are you sure you're not thinking of Temporal InterpretISODateTimeOffset step 8.c.i RoundNumberToIncrement(candidateNanoseconds, 60e9, "halfExpand")?

thanks for the detailed plan, i'd hate for it to get lost in the matrix chat, an issue to capture it would be great.

for (2), good to know it's independent. i won't be the one to drive this work, so Frank, who's much closer to the i18n and ICU teams, would be the one for you to convince to do the heavy lifting. frankly i just don't have the domain expertise and don't have a nose for the impact here to make a decision

@shu: thanks for the detailed plan, i'd hate for it to get lost in the matrix chat, an issue to capture it would be great.

https://github.com/tc39/ecma402/issues/806. Feedback welcome!

a = { b: x };
a = ({ b: x });
( { b: x } = a );
( ({ b: x }) = a ); // does not work

If you translate this example to the "setter-function" case, it is consistent:

a = b.x = c?.setY(d = e = 42);

would assign undefined to a and b.x

rbuckton: re: throw; it occurs to me that possibly

ThrowExpression: `throw` AssignmentExpression [lookahead ≠ ,]

might also work?

The alternative I had was this:

Expression :
  ThrowExpression
  CommaExpression

CommaExpression : // the old Expression production
  AssignmentExpression
  CommaExpression `,` AssignmentExpression

And you could potentially even drop ThrowStatement since it would be fully covered by ExpressionStatement (rather than a lookahead restriction in ExpressionStatement).

in particular, stuff like

let obj = {
  x: condition ? val : throw new Error('condition is not satisfied'),
  y,
};

reading the old thread, I have a comment which reads

Note the comma after the throw. How would you propose to forbid it? Would you even want to?

I don't know why it didn't occur to me that you could trivially forbid it with a lookahead...

another option, which I am... only kind of serious about, would be

`throw` AssignmentExpression [lookahead ∈ {`)`, `}`, `;`, EOF} ]