◀ Merged tasks: T4660.

T4660 is effectively the same, but this one has a slightly clearer description. See also discussion in https://secure.phabricator.com/T4671#7. See also T4661.

Some notes:

• We have multiple different date formats for dates near and far from the current time ("Mon, June 9", "June 9 2012").
• The date selection control can not reasonably respect a date format string.
• All of the date formats we use are unambiguous (that is, no 3/4/2014) so they may not be preferred by all users, but shouldn't be unduly confusing.

None of this is too tricky, but a proper implementation involves multiple format controls for date strings, and additional format controls for the date picker control.

Even Randal Monroe agrees that ISO 8601 is the one true date format -- https://xkcd.com/1179/

My primary concern here is that I strongly dislike adding options to the product (see T8227 for discussion). In most cases, I personally bear the brunt of the long-term cost of adding options.

The approach in D11155 resolves this by adding two new options ("recent date format", "not-so-recent date format"), and I worry it will imply a third option ("date selector order") and may lead to eventual introduction of a fourth option ("cutoff to switch between recent date format and not-so-recent date format").

I'd like to avoid this, so I prefer these approaches for UI formatting, from most-preferred to least-preferred:

1. Close this as wontfix; the date format we use is already unambiguous and locale-neutral.
2. Remove recent vs not-so-recnet dates so all dates have a consistent format; switch all dates to ISO 8601.
3. Remove recent vs not-so-recent dates so all dates have a consistent format; provide a single option to customize it.
4. Retain recent vs not-so-recent dates; provide two options (D11155).
5. Retain recent vs not-so-recent dates; provide three options (formats, plus when we switch).
6. Allow users to customize an arbitrarily large number of date formats based on how distant a date is.

I favor (1). I think (2) and (3) reduce "delight" and (4), (5) and (6) are not worth the effort and complexity. There's a slippery slope from (4) > (5) > (6), and (6) seems clearly terrible.

I'm fine with (3). I have a moderately strong preference for (3) over (4), (5), or (6). I don't think the "recent vs not-so-recent" feature is worth a config option (4) and definitely not worth two (5) or infinite (6).

If we do pursue (4), I think we should label these formats as "Short" / "Medium" / "Long" / "Full" or similar, and not specifically tie them to recency, and generally consider moving toward (3) (that is, fewer magical rules about which format is selected) to avoid moving toward (4) (that is, more configuration options around magic).

For the date-time selector:

1. Close this as wontfix; the format we use is already unambiguous and locale-neutral.
2. Reorder components to Y-m-d, provide no options.
3. Provide an additional option, separate from any options provided above, to reorder components.
4. Try to parse the options above to figure out how to reorder components; this won't always work and is generally a big mess and not really a practical solution.

I favor (1) here, too. I think (2) reduces "delight". I don't think (3) is worth the effort, and (4) is just bad from every perspective.

I'm fine with (3).

This isn't really a big deal, and my preference for throwing this in a hole and burning it isn't strong. These options are unlikely to cause an explosion in either engineering complexity or UI complexity. After D12881, date and time settings have their own panel, which further mitigates UI complexity. We almost certainly need to add more options here anyway for things which are not currently locale-neutral, like 12 hour vs 24 hour time.

This dovetails somewhat with T8060.

@chad, you tagged this with User Delight -- what's your preference in balancing these concerns?

@lpriestley, this overlaps at least somewhat with Calendar, particularly the date-time selector -- any thoughts here?

I would probably punt on this until we pursue true internationalization.

I think we should wait until we implement T8060. There will, undoubtedly be some javascript unpleasanstries that will influence the level of customization allowed for this. If we push the user preference patch now, the most inconvenient outcome is that there might be a need to split out format customizations into date selection control format and timestamp format, which is too much preference noise, if we can avoid it. The best outcome, as far as date selection controls go, would be if we can improve and simplify the date selection control, then find a way for the user preference to be the master of both controls and timestamps.

My primary concern here is that I strongly dislike adding options to the product

There is no need to have options. Remove all options, use the one and only (T5296#78304).

The most important aspect in flexibility is the ability to support all locales. MediaWiki uses a system largely based on PHP's date() for historical reasons, see Language::sprintfDate().

A modern application should rely on CLDR data: http://cldr.unicode.org/translation/date-time-patterns