diff mbox series

en_US: Minimize changes to date_fmt (Bug 25923)

Message ID 12762a4a-ada3-616a-1a16-98969e70bae4@redhat.com
State Committed
Commit 8cde977077b3568310c743b21a905ca9ab286724
Headers
Series en_US: Minimize changes to date_fmt (Bug 25923) |

Commit Message

Carlos O'Donell July 8, 2020, 9:13 p.m. UTC 
  This patch implements the fix for bug 25923, which is to minimize
the changes made by commit 7395f3a0efad9fc51bb54fa383ef6524702e0c49.
This includes swapping the month and day, and moving the year to the
end.

env LANG=en_US.UTF-8 \
GCONV_PATH=/home/carlos/build/glibc-review/iconvdata \
LOCPATH=/home/carlos/build/glibc-review/localedata \
date
Wed Jul  8 04:35:20 PM EDT 2020

$ date
Wed 08 Jul 2020 04:35:21 PM EDT

Andreas, I see that you did comment on this in 2019-03-29:
https://sourceware.org/bugzilla/show_bug.cgi?id=24046#c4

In the future if such issues that you notice are affecting your
users, please raise them upstream.

I pondered a bit the parse-ability of %e vs. %b, and settled
on the fact that a space-padded day of the month is easier to
split out and is what was originally present.

On the topic of d_t_fmt, I think the existing format in glibc
is not what US users want, but given that it's been present
since 1997 I would never want to change it without a very strong
justification. In the case of date_fmt, it was specifically
designed to allow users to control date's output. Even then
date_fmt is an undocumented value to be used with nl_langinfo
and requires reading headers and using _DATE_FMT or
_NL_W_DATE_FMT (wide char?). Thus I am ok with the 24H to 12H
change from 2019, and any script that wants a specific format
should be using it directly with date.

OK for glibc 2.32?

8< --- 8< --- 8<
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.
---
 localedata/locales/en_US | 7 +++++--
 1 file changed, 5 insertions(+), 2 deletions(-)

Comments

Florian Weimer July 9, 2020, 6:03 a.m. UTC | #1 
* Carlos O'Donell via Libc-alpha:

> diff --git a/localedata/locales/en_US b/localedata/locales/en_US
> index e71abf5d5c..15c6354fcf 100644
> --- a/localedata/locales/en_US
> +++ b/localedata/locales/en_US
> @@ -117,8 +117,11 @@ t_fmt   "%r"
>  % Appropriate AM/PM time representation (%r)
>  t_fmt_ampm "%I:%M:%S %p"
>  %
> -% Appropriate date and time representation for date(1)
> -date_fmt "%a %d %b %Y %r %Z"
> +% Appropriate date and time representation for date(1).  This is
> +% different from d_t_fmt for historical reasons and has been different
> +% since 2000 when date_fmt was added as a GNU extension.  At the end
> +% of 2018 it was adjusted to use 12H time (bug 24046) instead of 24H.
> +date_fmt "%a %b %e %r %Z %Y"
>  %
>  % Strings for AM/PM
>  %

Looks good to me.  I don't see any copy directives for en_US/LC_TIME, so
there should not be any indirect fallout from this change.

Thanks,
Florian
diff mbox series

Patch

diff --git a/localedata/locales/en_US b/localedata/locales/en_US
index e71abf5d5c..15c6354fcf 100644
--- a/localedata/locales/en_US
+++ b/localedata/locales/en_US
@@ -117,8 +117,11 @@  t_fmt   "%r"
 % Appropriate AM/PM time representation (%r)
 t_fmt_ampm "%I:%M:%S %p"
 %
-% Appropriate date and time representation for date(1)
-date_fmt "%a %d %b %Y %r %Z"
+% Appropriate date and time representation for date(1).  This is
+% different from d_t_fmt for historical reasons and has been different
+% since 2000 when date_fmt was added as a GNU extension.  At the end
+% of 2018 it was adjusted to use 12H time (bug 24046) instead of 24H.
+date_fmt "%a %b %e %r %Z %Y"
 %
 % Strings for AM/PM
 %