This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH] en_US: define date_fmt (bug 24046)
On 2018-12-31 02:14, Rafal Luzynski wrote:
> 31.12.2018 00:54 Aurelien Jarno <aurelien@aurel32.net> wrote:
> >
> >
> > The en_US locale use a 12h am/pm format in both d_fmt and d_t_fmt, which
> > is correct, but does not define date_fmt. This cause the default value
> > to be used, which is in 24h format.
>
> I thought it was deliberate. But indeed,
> AFAIK 24h clock is not commonly understood
> in the USA. Are you a local citizen and
> can you confirm?
I am not a local citizen. That said it has been reported in Debian bug
#877900, and confirmed by one local citizen I know.
> > [...]
> > Changelog
> > [BZ #24046]
> > * localedata/locales/en_US (date_fmt): Define.
>
> I'm not sure that your comment is wrong but
> when I add a new field I'm also trying to
> quote its value. I think it is weird that
> we quote a value when we change it but not
> when we define it for the first time.
I'll change that.
> > ---
> > ChangeLog | 5 +++++
> > localedata/locales/en_US | 3 +++
> > 2 files changed, 8 insertions(+)
> >
> > diff --git a/ChangeLog b/ChangeLog
> > index a2170167c7..8f90d99290 100644
> > --- a/ChangeLog
> > +++ b/ChangeLog
>
> Please remove changes to ChangeLog itself
> when posting here. It makes your patchwork
> impossible to apply. However, it's not a big
> problem in case of such a trivial patch.
I have git-merge-changelog and it takes care of merging the ChangeLog,
you just have to adjust the date if needed. However If people prefer I
stop changing the ChangeLog in my patches.
> > diff --git a/localedata/locales/en_US b/localedata/locales/en_US
> > index 5e2b365659..2c808bbfb6 100644
> > --- a/localedata/locales/en_US
> > +++ b/localedata/locales/en_US
> > @@ -117,6 +117,9 @@ t_fmt "%r"
> > % Appropriate AM/PM time representation (%r)
> > t_fmt_ampm "%I:%M:%S %p"
> > %
> > +% Appropriate date representation (date(1))
>
> I know that many locales have this comment
> already but can we invent something different
> to avoid nested parentheses here?
Something like "Appropriate date representation for the date utility"?
Regards,
Aurelien
--
Aurelien Jarno GPG: 4096R/1DDD8C9B
aurelien@aurel32.net http://www.aurel32.net