en_US: Minimize changes to date_fmt (Bug 25923)

In 2000 when date_fmt was originally added as an extension the
en_US locale did not have a date_fmt specifier and so used the
default which resulted in the abbreviated month name coming
before the day of the month (as expected in the US and other
locales).  In commit 7395f3a0efad9fc51bb54fa383ef6524702e0c49 the
date_fmt was added to en_US with a 12H time to better align with
US user expectations.  Unfortunately the abbreviated month name
and day were inverted during that transition, and that was seen
as a regression and reported against Fedora 32:
https://bugzilla.redhat.com/show_bug.cgi?id=1830623

The progression of date_fmt looks like this:
"%a %b %e %H:%M:%S %Z %Y"    <- Originally (2000)
"%a %d %b %Y %I:%M:%S %p %Z" <- glibc 2.29 (2019)
"%a %b %e %r %Z %Y"          <- glibc 2.32 (2020) [this commit]

Note: "%r" is "%I:%M:%S %p" in en_US and so shorter to write.

Likewise the year is in the wrong place in commit
7395f3a0efad9fc51bb54fa383ef6524702e0c49 and this is corrected in
this patch.

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

Yes, d_t_fmt and date_fmt are *not* the same, this is just the
history of this locale. This commit does not change d_t_fmt to
better align with date_fmt. No users have requested we change
d_t_fmt or given any justification for such a change.

The only goals of this change are to place the abbreviated month
name before the day of the month as it has been printed since
2000, and place the year at the end. This minimizes the change
from commit 7395f3a0efad9fc51bb54fa383ef6524702e0c49 and makes
good on changing only from 24H clock to 12H clock.

Reviewed-by: Florian Weimer <fweimer@redhat.com>

0 files changed, 0 insertions, 0 deletions