Semantic skeletons design

[aphillips]

trafficstars

This design document contains the proposed design for including semantic skeletons into Unicode MessageFormat's functions.

This PR is based on @sffc's doc

[sffc]

I agree with @eemeli's comment (😃) except I think we need more discussion on

I don't think the inclusion or not of the timezone in the output merits separate :zoned* variants of the functions; that should instead be controlled by a timeZoneName option as in JS. That option should be supported on :datetime and :time, but probably not on :date.

I've stated previously that I don't understand the mental model for having :date, :time, and :datetime but not :datetimezone (or :zoneddatetime). Just as a date is fundamentally different from a time, and a datetime is fundamentally different from a date or a time, a zoned datetime is fundamentally different from a date, time, or datetime. If we split date, time, and datetime into individual functions, why would we not do the same for the zoned versions?

[eemeli]

If we split date, time, and datetime into individual functions, why would we not do the same for the zoned versions?

I'd say it's because the timezone is a part of the time specifier. I do not see including or not the timezone as introducing a fundamental difference in the formatted output, though it's obviously a significant part of the input value that's being formatted.

[sffc]

1. May
2. May 15
3. May 15, 10 AM
4. May 15, 10:01 AM
5. May 15, 10:01 AM CEST

Can you explain a mental model for why you draw a line between only 2 and 3?

[eemeli]

Without a time, a date is describing a whole day or an even wider range. With a time, we're describing a specific instant. We speak of them differently.

So for example we don't think of "May 15" as implicitly meaning midnight or noon or any other time, but the whole day when multiple things could happen one after the other. Meanwhile, "May 15, 10 AM" conceptually expands to mean 10:00:00 on that day, a single moment in time. If it's not implicitly enough tied to a timezone, we might want to include one for disambiguation, but we're still speaking about a specific instant of time.

[sffc]

From the MF WG meeting this week, the following design seems worth exploring:

# A date formatter
{:datetime dateFields="YMD" }

# A time formatter
{:datetime timePrecision="minute" }

# A datetime formatter
{:datetime dateFields="YMD" timePrecision="minute" }

# A zoned datetime formatter
{:datetime dateFields="YMD" timePrecision="minute" zoneStyle="generic" }

[aphillips]

From the MF WG meeting this week, the following design seems worth exploring:

# A date formatter
{:datetime dateFields="YMD" }

# A time formatter
{:datetime timePrecision="minute" }

# A datetime formatter
{:datetime dateFields="YMD" timePrecision="minute" }

# A zoned datetime formatter
{:datetime dateFields="YMD" timePrecision="minute" zoneStyle="generic" }

I will add this to the design document under the :datetime design option.

[aphillips]

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 (from this design document) as an add on.

I added some material in e29b5e2 about field width management.

[macchiati]

With and without the timezone does make a difference of some 26 hours.

1. If I write that X happened on 2025 May 15 CEST, that gives you a specific 24 hour interval in which it happened. (Near a daylight savings transition, can be 23 or 25 hours.)
2. If I write that X happened on 2025 May 15, unless you assume a particular timezone, it gives me a roughly 50 hour interval in which it happened, from the first moment on earth that had May 15 00:00:00 (Kiribati), to the last moment on earth that had May 15 11:59:59.999... (Baker Island)