2023-03-10 [16:56:40.0773] Thanks so much to 402 team for taking the time today to discuss time zone canonicalization! 🙏 Proposal coming soon. [01:35:27.0748] I filed three issues based on the discussion yesterday: https://github.com/romulocintra/user-locale-client-hints/issues [01:35:50.0271] (Issues 13, 14, and 15) 2023-03-11 [18:29:23.0822] > <@justingrant:matrix.org> Thanks so much to 402 team for taking the time today to discuss time zone canonicalization! 🙏 Proposal coming soon. Proposal is started here: https://github.com/justingrant/proposal-canonical-tz#readme I just filed a [PR](https://github.com/tc39/agendas/pull/1339) to put this on the agenda for Stage 1 in the upcoming plenary meeting later this month. Feedback and issues are welcome! I'm happy to make changes before the meeting, or even to pull it from the agenda if there's something wrong. cc Richard Gibson 2023-03-14 [20:55:24.0512] Slides for the proposal above are here: https://docs.google.com/presentation/d/13vW8JxkbzyzGubT5ZkqUIxtpOQGNSUlguVwgcrbitog [21:00:03.0408] Different topic: is there a rough timeline for when ICU4X (specifically the parts that power time zone APIs) will be included in V8? Later this year? 2024? 2025? A few things I'be been working on lately, including the proposal above, may rely on ICU changes. So trying to get a sense for how whether those ICU changes would be in ICU4C (which I assume is harder to justify change given ICU4X is right around the corner) or ICU4X (which I assume is somewhat more flexible). [22:42:19.0353] The road to V8 running ICU4X is long. An example scenario is if we end 2023 with buy-in from all sides and then commit 2024 to doing migration and testing and roll something out in 2025. But to be clear there is no such consensus or agreement at this point. A number of V8 people are amenable to the idea but there is no official roadmap yet [22:44:17.0316] Got it, 2025 sounds like a reasonable target. Thanks for sharing. So essentially no proposal in the next year or so should depend on ICU4X, but nor should any proposal put big new requirements on ICU4C either. Sound right? [22:49:16.0438] Yes, although you're welcome to make that type of proposal, just don't expect it to ship [22:50:04.0749] Haha that's kinda what I meant. I'm not a big fan of working on things that won't ship. :-) [22:51:54.0846] If you're asking about this because of time zone canonicalization, I don't know for certain exactly how it fits in here. It certainly requires either a change to ICU4C or some other helper library. Perhaps one outcome could be that this is the first proposal to use ICU4X while other things are still on C. It's easier to sell incremental migration :) [05:44:50.0929] > <@justingrant:matrix.org> Got it, 2025 sounds like a reasonable target. Thanks for sharing. So essentially no proposal in the next year or so should depend on ICU4X, but nor should any proposal put big new requirements on ICU4C either. Sound right? by "depend on ICU4{C,X}" you're referring to implementation of a proposal by one or more pieces of software, right? Because ICU is not a thing that ECMA-402 can normatively reference, and we already have software that specifically does not use it for e.g. time zone canonicalization [05:58:24.0200] (I guess this is a proposal within Google, not a TC39 proposal) [05:58:55.0316] glad to hear that it's on the table to adopt ICU4X in V8 [05:59:02.0268] (even if not decided) [06:00:21.0374] Yes. "2025" was all I needed to know about ICU4X. Wanted to check if ICU already had what that proposal needs our whether new ICU APIs are needed. ICU4C seems like the places to look. ICU4C already has [`TimeZone::createEnumeration`](https://unicode-org.github.io/icu-docs/apidoc/released/icu4c/classicu_1_1TimeZone.html#aa6e783394f7a3ee95a0a650bd25d316b) and [`getCanonicalID`](https://unicode-org.github.io/icu-docs/apidoc/released/icu4c/classicu_1_1TimeZone.html#a7ec9cea4e406bd625e0fe1b058134b5c). That sounds like good news. [06:02:43.0581] * Yes. (Replying to Richatd) "2025" was all I needed to know about ICU4X. Wanted to check if ICU already had what that proposal needs our whether new ICU APIs are needed. ICU4C seems like the places to look. ICU4C already has TimeZone::createEnumeration and getCanonicalID. That sounds like good news. [06:04:02.0583] What was the ECMA-402 feedback on the time zone canonicalization proposal? [06:06:19.0891] TG2 encouraged me to write one. It's only 5 days old so I don't expect much feedback yet. 😀 [12:53:59.0180] We discussed the topic at length in last week's TG2 call, but before it was a proposal; see last week's email with notes 2023-03-22 [13:04:36.0709] is this the first TC39 meeting since I joined where no ECMA-402 proposals are brought up? YAY! :D [13:05:14.0990] There's the time zone canonicalization proposal [13:06:11.0033] ah [13:17:49.0531] Yep! If any TG2 folks have feedback on that time zone canonicalization proposal, it'd be great to hear it here today so we can make changes or address concerns before we present to the committee tomorrow. Slides: https://docs.google.com/presentation/d/13vW8JxkbzyzGubT5ZkqUIxtpOQGNSUlguVwgcrbitog [14:06:08.0779] sffc: what i18n data are you working with that can use binary16 values? [14:07:03.0486] Segmentation data [14:15:40.0843] why is that floating point at all? [14:17:04.0797] for the LSTM model. Currently we're running f32 arithmetic but we can store in f16 with no loss in accuracy. I haven't put time into whether we would want to do arithmetic in f16 or bf16 space directly. But if your weights are going to be converted back to f32, f16 makes more sense than bf16. [14:19:06.0957] Another place where floating point comes up in i18n is unit conversions. We could use decimals there instead, but f64 has been sufficient for formatting 2023-03-29 [10:24:35.0389] I added April, May, June, and late-June/July TG2 meetings to the calendar, all spaced 4 weeks apart. There are 11 weeks between the TG1 meeting in July and September, which means we need to decide whether to have 2 or 3 meetings in that span. The two choices are: 1. TG2 on 2023-07-27, 2023-08-24, and 2023-09-14 2. TG2 on 2023-08-03 and 2023-09-14 Preferences? 2023-03-31 [07:41:31.0198] leobalter ryzokuken could I trouble either of you for steps to publish the 2023 edition? I can probably muddle through by looking at the git history and old emails, but really I'd just like to document this and move on. [07:42:53.0791] leobalter did it the last couple of times [07:43:09.0465] using what has been described as "an oddly hacky setup of safari" [07:43:48.0732] I was considering trying pandoc for it [07:43:58.0821] so we could eventually write a script for it or something [07:46:04.0815] anything's fine with me as long as we document it [07:47:42.0668] https://wkhtmltopdf.org/ [07:47:47.0509] how does this look [07:48:18.0528] the repository-level changes look straightforward, basically an es$YYYY branch with frontmatter [`status: standard`](https://github.com/tc39/ecma402/commit/d063283b979bb6f65d487652c5f94c26b6551000) and some [number increments](https://github.com/tc39/ecma402/commit/11f1a85c8a6f544ddb10bdc0db9cc5c0fdaafa53) [07:50:01.0340] looks like ecma262 has partial automation for that: https://github.com/tc39/ecma262/commit/d048f32e861c2ed4a26f59a50d392918f26da3ba [07:52:23.0443] and also a [rendered version in gh-pages](https://github.com/tc39/ecma262/tree/gh-pages/2022), but possibly only once truly final