I've been clear about my concern with :date and :time, stated in #1067 (comment). I apologize that I didn't attend the 2025-06-02 meeting, but my concerns were made clear well before then.

I tend to agree with Shane's statement there. I see no value in the 3 way split; just more cumbersome for callers. Here's what he said:

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?

:time
:timeWithZone
:timeWithDayOfWeek
:timeWithZoneAndDayOfWeek
:date
:dateWithEra
...

An additional ergonomic issue with :date and :time is that it temps people to write messages such as {$input :date} at {$input :time} instead of {$input :datetime}.

@sffc noted:

An additional ergonomic issue with :date and :time is that it temps people to write messages such as {$input :date} at {$input :time} instead of {$input :datetime}.

That temptation is not always wrong. UX designers sometimes want to enrich the text by separating the fields.

@macchiati noted:

I tend to agree with Shane's statement there. I see no value in the 3 way split; just more cumbersome for callers.

The functions :date and :time have different functionality in this iteration. Without them :datetime might require an additional value of none for dateStyle/timeStyle to allow for part suppression and users have additional typing to get formatting they want.

As noted in the intro, this is NOT the final solution to date/time formatting. It's a stopgap while we decide on additional functions. I'm not opposed to reducing it to just :datetime, so long as we introduce no "deprecated at birth" functions, options, or option values. If that's not possible, we should focus on the final design instead of giving ourselves this breathing room.

To follow up on today's call:

I'm not fully convinced with pulling out :date and :time, but I would be reasonably satisfied if the Working Group published a statement explaining why those two formats are important enough to pull out into their own shortcut functions, similar to how we pull out :integer and are considering pulling out :percent. An answer of "well it just feels right" is acceptable, but then it will be harder to make arguments against adding things like :percent.

I would not be happy with an answer of "it was in MF1" because I have demonstrated how MF1 can be written on top of MF2 Semantic Skeletons. It needs to be independently motivated.

If we move forward with :date and :time, here are some examples of how they can be written to be future-proof with semantic skeletons:

In summary, 4 of the formats, perhaps the most common ones, are fairly easy to add in this framework without being very opinionated or making any decisions that are hard to roll back.

closed without merging. superseded by 1083