2026-04-03 [14:46:55.0947] i need some help understanding the Link stuff in https://tc39.es/ecma402/#sup-availablenamedtimezoneidentifiers [14:47:53.0791] if i do `new Intl.DateTimeFormat('en',{timeZone:'America/Kentucky/Louisville'}).resolvedOptions().timeZone`, and there's `Link America/Kentucky/Louisville America/Louisville` in the `backward` file in tzdb, does 402 say the result _must_ be `America/Kentucky/Louisville`? [14:48:32.0164] * if i do `new Intl.DateTimeFormat('en',{timeZone:'America/Louisville'}).resolvedOptions().timeZone`, and there's `Link America/Kentucky/Louisville America/Louisville` in the `backward` file in tzdb, does 402 say the result _must_ be `America/Kentucky/Louisville`? or [14:52:13.0499] When Temporal is merged along with the Time Zone Canonicalization proposal, the behavior will be to retain the input time zone name. CC justingrant, can you elaborate? [14:54:13.0128] am i correct in interpreting that to mean "currently 402 requires canonicalization, but once temporal merges input tz name is retained"? 2026-04-04 [12:13:24.0302] The following diff might answer your question: https://github.com/tc39/ecma402/pull/1044/changes#diff-aae61752e383a82db0847140fc85c3f1718f6348407153200b6db8462f10a21aR107 [15:22:20.0422] Yes, this matches my understanding of the spec text in https://tc39.es/proposal-temporal/#sec-intl-datetimeformat-constructor. [15:23:08.0435] shu The change that you mentioned is step 32c. 2026-04-05 [20:52:16.0427] Note that it's not exactly "tz name is retained" because that would imply that you need to save the actual string the user gave you. Instead, what you need to retain is the case-normalized string ("America/Denver" not "AmerICa/dENver") which allows implementations to store the time zone more efficiently, like as a 10-bit index into a list of supported ID strings. 2026-04-17 [01:31:05.0249] While looking into yesterday's topic, I learned that CSS text-transform in Firefox supports Irish, but CLDR/ICU does not. (Commented on https://unicode-org.atlassian.net/browse/ICU-23349 ) Also, CSS text-transform in Firefox has Turkish-like i behavior for Tatar, Crimean Tatar, and Baskir, which aren't listed in SpecialCasing.txt, which only lists `tr` and `az`. https://en.wikipedia.org/wiki/Common_Turkic_alphabet#Grapheme-phoneme_correspondences shows even more. Is there some CLDR/Unicode history here that I should be aware of? For example, are the Turkish-like rules for languages other than Turkish and Azerbaijani considered not establishe and stable enough for SpecialCasing.txt, or is it just a matter of no one having sorted this area out more comprehensively? [01:35:57.0541] The section 5.18.2 Complications for Case Mapping in the Unicode Standard is silent about Irish. [01:58:10.0667] Also regarding the same conversation from yesterday: I didn't realize until looking into it afterwards that the CSS `text-transform: capitalize` makes the first letter of _each word_ uppercase. My understanding of what we might want to consider for JS would be a transform that only affects the first letter of the entire string. Furthermore, the [MDN entry for `capitalize`](https://developer.mozilla.org/en-US/docs/Web/CSS/Reference/Properties/text-transform#capitalize) is accompanied by a warning as well as a note. That seems as clear an indicator as anything that There Be Dragons Here. [07:42:45.0534] > My understanding of what we might want to consider for JS would be a transform that only affects the first letter of the entire string. I think I'd push for only affecting the start of the first word-like segment, and possibly further requiring that segment to itself be first 2026-04-22 [07:18:36.0124] FYI, issue about year numbering in the Dangi calendar. Should this issue be moved to the 402 repo? https://github.com/tc39/proposal-temporal/issues/3308 [08:30:56.0429] oh, I've seen this one before in the ICU bugtracker. I'll try to hunt it down 2026-04-29 [05:53:59.0780] For inclusion on tomorrow's agenda, I've written up an initial draft of the spec text for Stable Formatting as well as filing a number of PRs implementing some changes based on the discussions about it at the 2025-02 TC39 plenary as well as what came up while working on the spec text. My hope is to be able to propose this for Stage 2 in Amsterdam: https://github.com/tc39/proposal-stable-formatting/pull/25 [05:54:53.0052] My newly-proposed changes include defining `und` behaviour for Collator, Segmenter, and toLocale{Lower,Upper}Case: https://github.com/tc39/proposal-stable-formatting/pull/24 [10:39:16.0547] * For inclusion on next week's agenda, I've written up an initial draft of the spec text for Stable Formatting as well as filing a number of PRs implementing some changes based on the discussions about it at the 2025-02 TC39 plenary as well as what came up while working on the spec text. My hope is to be able to propose this for Stage 2 in Amsterdam: https://github.com/tc39/proposal-stable-formatting/pull/25