Default to medium rather than short dateStyle

[eemeli]

I can't remember why/how we ended up with short being the default value for the :datetime dateStyle and timeStyle, and their :time and :date equivalents. Given how dates and times tend to be placed within text, I think that while short is a good default for time, long is better for dates.

In a JS en-US environment, we get:

short

• 7/1/24
• 4:20 PM
• 7/1/24, 4:20 PM

medium

• Jul 1, 2024
• 4:20:00 PM
• Jul 1, 2024, 4:20:00 PM

long

• July 1, 2024
• 4:20:00 PM GMT+3
• July 1, 2024, at 4:20:00 PM GMT+3

So the overall default for :datetime would be dateStyle=long timeStyle=short:

• July 1, 2024 at 4:20 PM

[aphillips]

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

[eemeli]

Not quite, without options the year uses four digits:

new Intl.DateTimeFormat('en').format(new Date) // '7/1/2024'
new Intl.DateTimeFormat('en', { dateStyle: 'short' }).format(new Date) // '7/1/24'

And it's by no means the only JS default that's available:

new Date().toString() // 'Mon Jul 01 2024 16:20:00 GMT+0300 (Eastern European Summer Time)'
new Date().toLocaleString('en') // '7/1/2024, 4:20:00 PM'

We should probably determine what defaults make sense for MF2 independently of JS legacies.

[aphillips]

We should:

• probably start with an issue
• include the design document, not just the registry
• establish some kind of basis for choosing defaults

JS's APIs and ICU's APIs are good influences to look at. FWIW, Java and ICU4J's default is the medium format.

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

I don't necessarily disagree with what's being proposed here, but we shouldn't just do things randomly. Note that this will be a normative change and we should act as-if stability rules are almost in place. Do we (or the ES folk) have any feedback on defaulting?

[eemeli]

include the design document, not just the registry

This PR includes updates to the design doc as well.

JS's APIs and ICU's APIs are good influences to look at. FWIW, Java and ICU4J's default is the medium format.

I think medium could also work, but that it 1) includes seconds for time which I'd claim to be less common than not including them, and 2) unnecessarily abbreviates month names.

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 of things, that carries a precondition of introducing skeletons in Intl.DateTimeFormat, which no-one's even proposed for the spec.

[aphillips]

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 of things, that carries a precondition of introducing skeletons in Intl.DateTimeFormat, which no-one's even proposed for the spec.

Actually, not necessarily. Option-bags are effectively verbose skeletons.

The thing you're calling out about e.g. medium is that the keywords are sometimes what one wants but are sometimes weird and sometimes different by locale--which is why I generally teach developers to always use skeletons (or equivalent) when available. That way you don't sometimes get seconds or sometimes get two-digit years.

That is, instead of choosing which dateStyle/timeStyle is default, we should say:

• {$dt :datetime} is equivalent to {$dt :datetime year=numeric month=short day=numeric hour=numeric minute=numeric}
• {$d :date} is equivalent to {$d :date year=numeric month=short day=numeric}
• {$t :time} is equivalent to {$t :time hour=numeric minute=numeric}

(we can quibble about which bag of options for each; note that I went with short month rather than an all-numeric as default)

[eemeli]

That is, instead of choosing which dateStyle/timeStyle is default, we should say:

• {$dt :datetime} is equivalent to {$dt :datetime year=numeric month=short day=numeric hour=numeric minute=numeric}
• {$d :date} is equivalent to {$d :date year=numeric month=short day=numeric}
• {$t :time} is equivalent to {$t :time hour=numeric minute=numeric}

This is problematic in at least two different ways:

1. :date and :time do not currently support field options.
2. At least ECMA-402 does not define what the full/long/medium/short date & time styles actually mean, and permits them to vary per locale.

I at least would be much happier with sticking with short dates rather than opening up the can of worms implicitly proposed by the above. The intent with this PR is to make a small change to the date formatting default value. Rethinking the whole approach and ECMA-402 compatibility should be a separate matter.

[aphillips]

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 to {$d :datetime year=numeric month=short day=numeric}
• {$t :time} is equivalent to {$t :datetime hour=numeric minute=numeric}

402 doesn't define what they mean on purpose because CLDR doesn't either. They do vary by locale. This makes a kind of sense, but it also means that developers and user experience designers can get into trouble (by expecting that the fields will be the same as US English). What's more, as you've already shown, it means that the default format isn't necessarily any of the enumerated values (although it might be).

The intent with this PR is to make a small change to the date formatting default value. Rethinking the whole approach and ECMA-402 compatibility should be a separate matter.

Perhaps. I think we need to finish off the date/time stuff, because what we have is insufficient for real world users. The canned formats are not what UX designers are looking for in many applications. And you can't get very far without dealing with timezones/floating time values. We don't address either currently.

Our defaults should be reasonable for users to sometimes use them. We shouldn't create a ton of work for our implementers, but we shouldn't adopt defaults that are not very useful either (even if 402 has). I agree with you that short is not a particularly useful default for dates from a "good I18N habits" point of view (it's all numeric which can make it sometimes ambiguous, e.g. 11/10/09). Let's discuss.

[aphillips]

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.

[aphillips]

In the 2024-07-15 call we agreed to default to medium. Removing agenda+. Adding action-item for @eemeli to update the PR

[aphillips]

LGTM