2026-02-02 [12:49:23.0682] Apologies if this is frowned upon, but: https://front-end.social/@Wilto/116002214854625680 [12:49:51.0435] * Apologies if this sort of thing is frowned upon here, but: https://front-end.social/@Wilto/116002214854625680 [15:38:23.0855] This channel is for ECMA-402, but Explicit Resource Management is an ECMA-262 proposal 2026-02-03 [06:00:05.0495] Sorry about that! 2026-02-04 [11:46:20.0299] @sffc:mozilla.org do you know when Chrome plans to ship throwing RangeError in `Intl.DateTimeFormat` for legacy non-IANA tzs? [12:38:33.0172] You mean the Time Zone Canonicalization proposal? I don't think throwing in that circumstance is part of the proposal [12:56:25.0448] i mean i mean https://github.com/tc39/test262/blob/main/test/intl402/DateTimeFormat/timezone-legacy-non-iana.js, i don't think that's the time zone canonicalization proposal [12:56:32.0217] * i mean https://github.com/tc39/test262/blob/main/test/intl402/DateTimeFormat/timezone-legacy-non-iana.js, i don't think that's the time zone canonicalization proposal [12:57:48.0011] I see. I was unaware of this issue. [12:57:59.0001] Is there a crbug for it? 2026-02-05 [20:28:24.0816] What is the context around this request? Did these non-IANA names previously work in Chrome? If so, how did they work? I ask because I don't see "JST" in https://github.com/unicode-org/cldr/blob/main/common/bcp47/timezone.xml which is AFAIK the data source for time zone IDs used by ICU4C. And, aside from naming, where does the time zone rules for each of these non-standard zones come from? Are each of these simply aliases to an IANA zone or do some/all have distinct rules? [20:40:43.0771] Oh, I didn't see the link in the test the first time I read it. Now I understand. Are we seeing customer complaints about these zones? [20:41:13.0804] * Oh, I didn't see the link in the test the first time I read it. Now I understand. Are we seeing customer complaints about these zones? Context: https://github.com/tc39/test262/blob/main/test/intl402/DateTimeFormat/timezone-legacy-non-iana.js [20:58:08.0487] Does Firefox currently pass this test, and Chrome fails? Where does Safari land? [21:10:01.0254] * Oh, I didn't see the link in the test the first time I read it. Now I understand. Are we seeing customer complaints about (the lack of) these zones? Context: https://github.com/tc39/test262/blob/main/test/intl402/DateTimeFormat/timezone-legacy-non-iana.js [21:10:29.0136] Current Safari accepts these legacy zones. 2026-02-06 [11:28:37.0799] Safari wants to align with Firefox and would like signals from Chrome [11:29:49.0479] yeah, this broke some stuff internally; unclear to me extent of web breakage [11:30:31.0459] namely i suspect PST is gonna break stuff [11:37:03.0121] "wants to" is perhaps too strong: we prefer to be standards compliant given this is the current behavior, but chrome has not yet shipped so we want to know either that they plan to implement, or they plan to propose to change the spec [11:38:09.0690] I would not want to change the spec here: requiring all implementations to support time zone names that have been deprecated for many years (decades?) seems like a bad idea. [11:40:05.0802] i also haven't filed a bug against chromium for this, @sffc:mozilla.org mind filing one? 2026-02-07 [17:35:47.0228] I feel like the chances someone wrote code saying time zone: "PST" and never thought of testing it in Firefox is pretty high [17:36:47.0750] But I suspect Chrome has been out of conformance here for quite some time [17:37:11.0980] The next step is to file a crbug 2026-02-19 [09:52:28.0554] Firefox only implements https://tc39.es/ecma402/#sec-lookupmatchinglocalebyprefix . I hear from sffc that Chrome doesn't implement it and only delegates to ICU4C's lookup as https://tc39.es/ecma402/#sec-lookupmatchinglocalebybestfit . What does Safari do for lookup? [10:24:47.0798] It looks to me that Chromium does have two distinct lookup algorithms. [11:17:13.0439] Looks like WebKit/JSC does what Gecko/SpiderMonkey does. [11:17:35.0587] I.e. https://tc39.es/ecma402/#sec-lookupmatchinglocalebyprefix only. 2026-02-20 [22:14:37.0128] "prefix only" is not a good algorithm because it doesn't handle parent relationships and multi script locales well [22:17:06.0178] I assume it was added because the authors wanted to define an algorithm that could be reasonably implemented without ICU, not because they thought anyone should actually use it. [22:22:00.0897] A specific flaw with "prefix only", as I mentioned to Henri earlier, is it doesn't allow for engine optimizations like making Chinese Hans/Hant inherit from a common ancestor for collations. [13:48:36.0945] FWIW, we ran into a case where a developer on Linux wrote code that parsed the output of the `date` command and assumed that they could pass that output's time zone acronym (e.g. EST) to Temporal. This broke for Pacific time because EST and MST are valid IDs in IANA but PST and CST are not. Also not EDT, CDT, MDT, PDT. Not sure what to make of this. On one hand, using those acronyms is hugely fragile, won't work worldwide, and we don't want anyone to use them in Temporal/Intl. On the other hand, crashing is bad. 2026-02-23 [11:02:05.0636] sffc: Does Chromium make good use of what better than prefix only should enable relative to Firefox and Safari? For example, is it better for yue? [11:04:05.0825] Is there a good reason why Chrome unshipped zh-u-co-unihan but keeps ja-u-co-unihan and ko-u-co-unihan? Or is this just a case of someone having looked at unshipping Chinese collations (unihan getting unshipped together with big5han and gb2312) instead of looking at more things at the same time? [11:05:55.0262] The way Firefox deals with prefix-only, Hans, and Hant is ensuring the common triplets are in the the available locales list. [11:06:15.0778] Common triplets starting with zh, that is. We don't have yue on the list. [11:06:50.0820] There's a big mismatch between what the spec says and how i18n libraries actually work. Even if you implement the spec as written, as soon as you start asking ICU to do things, you are implicitly getting the best fit behavior. [11:07:20.0130] The whole concept of "available locales" just simply doesn't exist [11:07:58.0917] sffc: We run the spec algorithm first. Passing its outcome to either ICU4C or ICU4X gives the expected result. That is, they don't do anything strange enough to break the outcome of the specced algorithm. [11:08:38.0536] It concretely exists in all of SpiderMonkey, JSC, and V8. [11:08:53.0091] What does exist is "class of locales that are vetted" and "class of locales that are not vetted", where the union of those classes is the space of all locales, which is a virtually unbounded set [11:09:17.0046] The spec is inventing a concept that no ICU has ever really implemented [11:09:59.0893] sffc: SpiderMonkey and V8 at least get the list from ICU4C today, so evidently ICU4C implemented something close enough to it. [11:10:32.0001] sffc: I understand why you think the list is a bad idea, but it really does exist in implementations. [11:11:48.0560] It's not that the list is a bad idea [11:11:53.0232] sffc: Do you have any insight into the unihan situation in Chrome? [11:12:18.0533] It's that the list is a list that doesn't exist; it's asking for a thing that is not real [11:14:14.0456] I don't remember exactly why Chrome does what it does with unihan collations [11:14:54.0381] hi-Latn is another example where best fit matching works but prefix matching not [11:16:13.0804] I have thoughts on how engines using ICU4X can implement the spec concept of available locales, which I've previously posted in issue 58 but never did a formal write up or docs page [11:22:30.0608] I wonder if anyone has bothered to do telemetry for traditional collations. For es, the traditional one is famous, but do people still want it? For fi and sv, it's not useful to ship traditional. Do people care about traditional for Vietnamese, Kannada, and Bengali? [11:58:29.0536] > <@sffc:mozilla.org> I have thoughts on how engines using ICU4X can implement the spec concept of available locales, which I've previously posted in issue 58 but never did a formal write up or docs page You deserve this writeup, and it will help Boa and V8, too. I'll put it on my list of things to do. Hopefully within a few weeks if that's okay. [12:00:53.0765] This would be nice! In Boa we kinda do very weird things to implement the concept of available locales, so it would be reassuring having an "official" way of implementing it using ICU4X