Addison Phillips

> From the MF WG meeting this week, the following design seems worth exploring: > > ``` > # A date formatter > {:datetime dateFields="YMD" } > > # A...

In the 2025-06-02 call, we discussed that in LDML48 we might include as stable only the basic `:datetime`, `:date` and `:time` functions with `dateStyle`/`timeStyle`/`style` options... and provide a complete solution...

@macchiati Please use separate issues for separate issues. --- Regarding the use of the term registry and the term default registry, I agree. We switched to a prose registry fairly...

@macchiati >Would it be appropriate for me to create a PR for doing that? No. I'm making a separate issue and PR now.

I think all of the issues here have been addressed. If not, a separate issue for each is probably warranted. resolve-candidate so we consider for close in the 2024-11-11 call

It's the default because that's what `Intl.DateTimeFormat` does.

We should: - probably start with an issue - include the [design document](main/exploration/default-registry-and-mf1-compatibility.md), not just the registry - establish some kind of basis for choosing defaults JS's APIs and ICU's...

> > Personally... I think we should get skeletons (or their proxy) in and encourage that they always be used (rather than the sometimes-inconsistent enumerations). > For the JS side...

The first problem could be addressed by making `:date` and `:time` be patches on `:datetime` (although we need to add field/skeleton customization to them anyway): - `{$d :date}` is equivalent...

This was discussed briefly in the 2024-07-08 call (which I missed). Adding to the agenda for 2027-07-15 so that we can resolve it.