Regression for en_US date_fmt (Bug 25923)

[Carlos O'Donell]

On 5/5/20 6:58 PM, Rafal Luzynski wrote:
> 5.05.2020 17:21 Aurelien Jarno <aurelien@aurel32.net> wrote:
>>
>> Hi,
>>
>> On 2020-05-05 09:59, Carlos O'Donell wrote:
>>> Aurelien,
>>>
>>> What do you think about this regression?
>>>
>>> https://sourceware.org/bugzilla/show_bug.cgi?id=25923
>>
>> Sorry it looks like that I indeed overlooked that change.
>>
>>> I'd like to minimize the changes we make to the en_US locale.
>>>
>>> Do you think undoing the month and date order change is best?
>>
>> I think it's pretty fine if it confuses the user to have the month and
>> day order reverted. Now I still believe that date_fmt and d_t_fmt
>> should use the same order, so I wonder if both should be swapped, to
>> actually match the C locale beside the 12h clock part.
> 
> Indeed, according to CLDR [1] the preferred order is m-d-y.  Sorry about
> overlooking it here, as well.
> 
> Should we swap?  Backport?

d_t_fmt:
"%a %d %b %Y %r %Z"          <- d_t_fmt    (1997) [For reference]

date_fmt:
"%a %b %e %H:%M:%S %Z %Y"    <- Originally (2000)
"%a %d %b %Y %I:%M:%S %p %Z" <- In 2.29    (2019)
"%a %b %e %r %Z %Y"          <- Suggested  (2020)

Originally in 2000 we had month before year, but 24h clock.
In 2019 we fixed the 24h clock, but swapped the month and day.

In 2020 I suggest we move back to the original date format as closely
as we can, leaving the clock as 12h as this was the original bug.

Yes, d_t_fmt and date_fmt are *not* the same, this is just the history
of this locale. I do not propose we change this.

Thoughts?

-- 
Cheers,
Carlos.