Use a date in General Settings greater than the 12th day for clarity at a glance

[garrett-eclipse]

Hello,

Currently the General Settings for Date Format uses the current date to populate the available format options. This works as expected but I find at a glance if the current day is less than the 12th day of the month it's hard to distinguish the m/d/Y vs d/m/Y format. If a more standard date that's greater than 12 is used it makes it easier to distinguish the two formats at a glance as it's easy to tell which number is the day vs the month as months only go up to 12.

I hope I've explained that, screenshot coming.

Cheers

[garrett-eclipse]

At a glance date format had to tell.

[knutsp]

Below the radio buttons there is a Preview. I suggest a second preview date and time following the current, for both date and time. Time should be PM.

[Rarst]

I get your point in principle for arbitrary date (which is why I by far prefer ISO formats in practice, e.g. 2019-10-07).

However in this specific instance the date is not ambiguous, it uses the current day and is immediately followed by human-readable format value.

I am not sure what practical improvement is possible here.

We could do something like Go with standardized value for date examples, but frankly I find that harder to explain than PHP formats.

[johnbillion]

Devil's advocate: If the date is ambiguous on the General Settings screen, it'll be ambiguous for your users.

[Rarst]

After thinking on this for a while, I feel the improvement is insufficient to change existing behavior here.

This would be a stronger argument for initial design, but for something that has been in place for a very long time, and is sufficiently clear with explicit date formats, it's not worth messing with.

There has been proposal for rethinking and extending use of date formats in general, but it doesn't have traction at the moment. If it picks up steam we can revisit how we present the options as part of larger change.

[garrett-eclipse]

Sounds good, thanks @Rarst

[sabernhardt]

#51499 was marked as a duplicate.