Shane F. Carr

I believe that the following code has worked since Intl 1.0, and it seems like a reasonable thing to write: ```javascript new Date().toLocaleTimeString("en", { timeZoneName: "long" }) '12:56:33 PM Pacific...

Yes, I agree that I think this was a questionable design choice. It's only that the bar for changing a feature that has been working for 10 years is high,...

TG2 discussion: https://github.com/tc39/ecma402/blob/main/meetings/notes-2025-07-17.md#normative-dont-add-default-formatting-to-lone-timezonename-958 I'm seeking agreement on the following proposed conclusion: > We feel that the proposed behavior is better, but we are skeptical that making this change would not...

TG2 agreed to the above conclusion. https://github.com/tc39/ecma402/blob/main/meetings/notes-2025-08-14.md#normative-dont-add-default-formatting-to-lone-timezonename-958

There is still `NeoNeverMarker`.

It could also be named `new_invariant` given that in Segmenter we call it `InvariantOptions`.

I've seen similar issues come in multiple times throughout ICU4X's lifetime. It definitely seems that there is demand for some API that takes some garbagey locale-like string and makes it...

We've designed ICU4X to optimize for `from_iso` being an efficient operation. The only inefficiency left are the far-away Chinese and Dangi dates, but we have a path forward to resolve...

> [@sffc](https://github.com/sffc) Yeah, though I do wonder if there's still a cost of `from_iso` being called 10-12 times when it comes to formatting. Context? That shouldn't need to happen; it's...

An `ffi::Date` wraps a `Date`, so when formatting, you should be able to convert your epoch time\* to a calendar date once, and then read all the fields. \* It...