8000 Include :datetime, :date, and :time with style options only by eemeli · Pull Request #1077 · unicode-org/message-format-wg · GitHub
[go: up one dir, main page]
Skip to content

Include :datetime, :date, and :time with style options only #1077

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Open
wants to merge 2 commits into
base: main
Choose a base branch
from
Open

Include :datetime, :date, and :time with style options only #1077

wants to merge 2 commits into from

Conversation

eemeli
Copy link
Collaborator
@eemeli eemeli commented Jun 8, 2025

As discussed on the 2025-06-02 call, this PR removes the "Draft" status from the :datetime, :date, and :time functions, while leaving their field options as "Draft". The intent here is to allow at least some datetime formatting to be made available while discussions are #1067 are ongoing.

@eemeli eemeli mentioned this pull request Jun 8, 2025
Open
aphillips
aphillips reviewed Jun 8, 2025
View reviewed changes
catamorphism
catamorphism approved these changes Jun 9, 2025
View reviewed changes
Copy link
Collaborator
@catamorphism catamorphism left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM with Addison's suggested changes

@eemeli @aphillips
Apply suggestions from code review
38b4bbe 
Co-authored-by: Addison Phillips <addison@unicode.org>
@eemeli eemeli requested a review from aphillips June 9, 2025 14:16
sffc
sffc requested changes Jun 9, 2025
View reviewed changes
Copy link
Member
@sffc sffc left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We haven't agreed to land :date and :time.

@sffc
Copy link
Member
sffc commented Jun 9, 2025

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.

@macchiati
Copy link
Member

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
...

@sffc
Copy link
Member
sffc commented Jun 9, 2025

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}.

@aphillips
Copy link
Member

@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.

@sffc
Copy link
Member
sffc commented Jun 16, 2025 •
edited
Loading

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:

Style Potential Syntax Comment
Date Short {$input :date length=short} Field set defaults to YMD, and otherwise an exact match
Date Medium {$input :date} ^ and length defaults to medium
Date Long {$input :date length=long} ^^
Date Full {$input :date fields=YMDE} This treads into how we specify field sets. Defer to 49?
Time Short {$input :time precision=minute} Defer to 49?
Time Medium {$input :time} Works if time precision defaults to seconds
Time Long {$input :time zoneStyle=specificShort} Requires options. Defer to 49?
Time Full {$input :time zoneStyle=specificLong} Requires options. Defer to 49?

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.

@sffc sffc mentioned this pull request Jun 17, 2025
Open
@eemeli eemeli mentioned this pull request Jun 23, 2025
Open
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@sffc sffc sffc requested changes

@catamorphism catamorphism catamorphism approved these changes

@gibson042 gibson042 Awaiting requested review from gibson042

@mihnita mihnita Awaiting requested review from mihnita

@aphillips aphillips Awaiting requested review from aphillips

Requested changes must be addressed to merge this pull request.

Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
5 participants
@eemeli @sffc @macchiati @aphillips @catamorphism