2023-01-10 [19:30:41.0769] > <@sffc:mozilla.org> I added the ECMAScript label to the issue. They will triage it soon sffc: That CLDR bug (https://unicode-org.atlassian.net/browse/CLDR-16243) is still not triaged yet. Expected? [20:22:36.0209] I think they haven't had much time to triage things over the holidays, but I can put the ticket on the agenda [20:22:51.0619] That'd be great, thanks Shane! 2023-01-11 [09:43:29.0265] They accepted the ticket for CLDR 43 [09:56:39.0746] Also: Richard Gibson filed a few more issues against NFv3. I want to put it up for Stage 4 at TC39 this month, and the last TG2 meeting before then is tomorrow, so if anyone has any lingering NFv3 issues, please file them today so we can discuss them 2023-01-18 [15:49:21.0188] Hey dminor or anyone else who knows: which versions of Firefox are supporting NFv3? I checked today and FF 108 does not seem to support it at all, but I definitely recall seeing an FF version that supported it recently. 2023-01-19 [05:59:26.0413] sffc: It's only enabled in Nightly builds at the moment, we have https://bugzilla.mozilla.org/show_bug.cgi?id=1795756 filed to enable it in release. 2023-01-31 [12:56:07.0006] 402 friends: in today's plenary meeting, we were unable to reach consensus on https://github.com/tc39/proposal-temporal/pull/2479. There are currently no comments from TG2 folks in that PR, nor in the original issue https://github.com/tc39/proposal-temporal/issues/2013 that's been open for more than a year. Could I humbly ask that comments be added into the PR ASAP (ideally today, or tomorrow morning) to explain any objections? This is not a complex change so hopefully it should be a quick review. If there are no (or easy-to-resolve) objections, then maybe we could ask again for consensus during the overflow topic we already have planned for later in this plenary week. To summarize the change: * If the argument to `format` or `formatToParts` is a `Temporal.ZonedDateTime`, then use that instance's `timeZone` property instead of the user's time zone. * If the formatter had a non-undefined `timeZone` option passed to the its constructor, and if that option doesn't match (after canonicalization) the `timeZone` property of the `ZonedDateTime` instance, then throw a `RangeError`. * This is similar to our already-agreed-upon behavior for handling mismatches between the `calendar` option in the DTF constructor vs. the `calendar` option of various Temporal types, except that with calendars the `iso8601` calendar on the Temporal side will never cause a mismatch because we treat it as a null/default calendar. With time zones on other hand, there is no obvious default so all mismatches will throw. * The behavior described above matches the behavior of `ZonedDateTime.p.toLocaleString()`. It's OK if there are blocking issues with the proposed fixes above, but we're all working very hard to close down any remaining open issues in Temporal. We really want to get the near-final form of this proposal into polyfill users' hands ASAP so we can ensure that no other regressions or problems come up. I realize this is just one PR among many, but we're down to hopefully the last few issues so every one we resolve this week will be helpful to the general goal of getting Temporal ready to ship. Thanks! [13:09:03.0855] * 402 friends: in today's plenary meeting, we were unable to reach consensus on https://github.com/tc39/proposal-temporal/pull/2479. There are currently no comments from TG2 folks in that PR, nor in the original issue https://github.com/tc39/proposal-temporal/issues/2013 that's been open for more than a year. Could I humbly ask that comments be added into the PR ASAP (ideally today, or tomorrow morning) to explain any objections? This is not a complex change so hopefully it should be a quick review. If there are no (or easy-to-resolve) objections, then maybe we could ask again for consensus during the overflow topic we already have planned for later in this plenary week. To summarize the change: - If the argument to `format` or `formatToParts` is a `Temporal.ZonedDateTime`, then use that instance's `timeZone` property instead of the user's time zone. - If the formatter had a non-undefined `timeZone` option passed to its constructor, and if that option doesn't match (after canonicalization) the `timeZone` property of the `ZonedDateTime` instance, then throw a `RangeError`. - This is similar to our already-agreed-upon behavior for handling mismatches between the `calendar` option in the DTF constructor vs. the `calendar` option of various Temporal types, except that with calendars the `iso8601` calendar on the Temporal side will never cause a mismatch because we treat it as a null/default calendar. With time zones on other hand, there is no obvious default so all mismatches will throw. - The behavior described above matches the behavior of `ZonedDateTime.p.toLocaleString()`. It's OK if there are blocking issues with the proposed fixes above, but we're all working very hard to close down any remaining open issues in Temporal. We really want to get the near-final form of this proposal into polyfill users' hands ASAP so we can ensure that no other regressions or problems come up. I realize this is just one PR among many, but we're down to hopefully the last few issues so every one we resolve this week will be helpful to the general goal of getting Temporal ready to ship. Thanks! [13:09:28.0887] It may be useful to add this to the 402 agenda next week if you can't get consensus before then [13:10:52.0642] It looks overall okay. Not sure about the semantics of conflicting time zones. I think it's fine. [13:11:21.0496] Ideally we could get a quick review before then (before the TC39 plenary is over). If there are substantial objections that can't be quickly resolved offline, then it's OK to bring to the 402 meeting but if there's no objections just not reviewed yet, I was hoping we could move fwd in this plenary. [13:11:40.0526] I thought I recalled us discussing that conflicting time zones would simply be ignored? [13:12:36.0515] > <@sffc:mozilla.org> I thought I recalled us discussing that conflicting time zones would simply be ignored? ptomato: do you have context about that? [13:16:01.0601] I don't remember anything like that, but I'll look in the notes [13:20:37.0662] https://github.com/tc39/ecma402/issues/750 [13:21:54.0548] oh, I see now you were proposing it there - I must have missed that due to the other question about the bug [13:30:14.0841] I think the main footgun is if the datetime formatter is configured to not display the time zone. Because then there's not a way for the user to tell what time zone the date is being displayed in. [14:29:47.0035] Shane, is there a specific behavior change that you'd recommend in that case? And would you want to see that behavior in `ZonedDateTime.p.toLocaleString()` too? [14:36:33.0336] Is it possible to create a formatter with `{timeZoneName: "none", timeZone: "America/McMurdo"}`?