Patchwork en_US: define date_fmt (bug 24046)

login
register
mail settings
Submitter Aurelien Jarno
Date Dec. 30, 2018, 11:54 p.m.
Message ID <20181230235437.20485-1-aurelien@aurel32.net>
Download mbox | patch
Permalink /patch/30905/
State New
Headers show

Comments

Aurelien Jarno - Dec. 30, 2018, 11:54 p.m.
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.

This patch adds the date_fmt entry to the en_US locale with the same
value as d_t_fmt as the latter already includes the timezone.

Changelog
	[BZ #24046]
	* localedata/locales/en_US (date_fmt): Define.
---
 ChangeLog                | 5 +++++
 localedata/locales/en_US | 3 +++
 2 files changed, 8 insertions(+)
Rafal Luzynski - Dec. 31, 2018, 1:14 a.m.
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?

> [...]
> 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.

> ---
>  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.


> 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?

Otherwise looks OK.  This is the last day
before freeze so please wait several hours
and feel free to push to master if nobody
complains and if you are sure it is correct.

I'm out of my PC, unable to test, posting
from my phone.

Regards,

Rafal
Aurelien Jarno - Dec. 31, 2018, 9:30 a.m.
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
Florian Weimer - Dec. 31, 2018, 10:53 a.m.
* Aurelien Jarno:

> 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.

Perhaps this format was chosen for alignment with asctime?
Is there any system which uses 12h format with the date command?

I wonder whether our users expect such a change.
Aurelien Jarno - Dec. 31, 2018, 11:07 a.m.
On 2018-12-31 11:53, Florian Weimer wrote:
> * Aurelien Jarno:
> 
> > 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.
> 
> Perhaps this format was chosen for alignment with asctime?

I don't think this has been a deliberated choice. Support for date_fmt
(which is a GNU extension), has been added back in 2000 in commit
d8337213c8. At that time all locales got date_fmt set to the default
setting, and later locales got this value updated through the years.
This has never been done for the US locale. Then in commit 2e7a461328
all locales with the default value got this field removed.

> Is there any system which uses 12h format with the date command?

Yes, the following locale use a 12h format with the date command:
aa_DJ aa_ER aa_ET am_ET az_IR byn_ER el_CY el_GR fa_IR gez_ER gez_ET
ku_TR lzh_TW om_ET om_KE sid_ET so_DJ so_ET so_KE so_SO ti_ER ti_ET
tig_ER uz_UZ wal_ET

> I wonder whether our users expect such a change.

At least a few users, but I agree it's difficult to know for the
majority of users.

Regards,
Aurelien
Florian Weimer - Dec. 31, 2018, 11:11 a.m.
* Aurelien Jarno:

>> Is there any system which uses 12h format with the date command?
>
> Yes, the following locale use a 12h format with the date command:
> aa_DJ aa_ER aa_ET am_ET az_IR byn_ER el_CY el_GR fa_IR gez_ER gez_ET
> ku_TR lzh_TW om_ET om_KE sid_ET so_DJ so_ET so_KE so_SO ti_ER ti_ET
> tig_ER uz_UZ wal_ET

Sorry, I meant other UNIX-like systems that use 12h format by defaul,
without any specific locale selection.
Aurelien Jarno - Dec. 31, 2018, 1:59 p.m.
On 2018-12-31 12:11, Florian Weimer wrote:
> * Aurelien Jarno:
> 
> >> Is there any system which uses 12h format with the date command?
> >
> > Yes, the following locale use a 12h format with the date command:
> > aa_DJ aa_ER aa_ET am_ET az_IR byn_ER el_CY el_GR fa_IR gez_ER gez_ET
> > ku_TR lzh_TW om_ET om_KE sid_ET so_DJ so_ET so_KE so_SO ti_ER ti_ET
> > tig_ER uz_UZ wal_ET
> 
> Sorry, I meant other UNIX-like systems that use 12h format by defaul,
> without any specific locale selection.

I don't think that's the case. UNIX-like systems are supposed to follow
POSIX, and "%X" and "%c" are defined in 24h format without locale
selection.
Rafal Luzynski - Dec. 31, 2018, 6:02 p.m.
31.12.2018 10:30 Aurelien Jarno <aurelien@aurel32.net> wrote:
> [...]
> 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.

AFAIK yes, people prefer this.  This is not my personal requirement,
I was asked not to post changes to ChangeLog before.

> 
> > > 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"?

I used "Appropriate date and time representation for date(1)" but
I don't claim that my version is perfect.  However, please note that
I used "date and time" and this sounds for me more accurate than just
"date".

Otherwise, thank you for your effort.

Regards,

Rafal
Rafal Luzynski - Dec. 31, 2018, 6:11 p.m.
31.12.2018 14:59 Aurelien Jarno <aurelien@aurel32.net> wrote:
> 
> On 2018-12-31 12:11, Florian Weimer wrote:
> > * Aurelien Jarno:
> > 
> > >> Is there any system which uses 12h format with the date command?
> > >
> > > Yes, the following locale use a 12h format with the date command:
> > > aa_DJ aa_ER aa_ET am_ET az_IR byn_ER el_CY el_GR fa_IR gez_ER gez_ET
> > > ku_TR lzh_TW om_ET om_KE sid_ET so_DJ so_ET so_KE so_SO ti_ER ti_ET
> > > tig_ER uz_UZ wal_ET
> > 
> > Sorry, I meant other UNIX-like systems that use 12h format by defaul,
> > without any specific locale selection.
> 
> I don't think that's the case. UNIX-like systems are supposed to follow
> POSIX, and "%X" and "%c" are defined in 24h format without locale
> selection.

This patch is for en_US only and I don't think that POSIX says it should
be 24h clock in every locale.  en_US locale is not default, it is used
only when explicitly requested.  Although I am aware that usually it is
usually preset.  But it does not overwrite POSIX.

I think that it should be 12h in en_US locale and in every locale where
people request it.  It's not hurting anyone using a different locale
(modulo those who use “copy "en_US"” but I assume they do it deliberately.)

Regards,

Rafal
Rafal Luzynski - Dec. 31, 2018, 6:16 p.m.
31.12.2018 12:07 Aurelien Jarno <aurelien@aurel32.net> wrote:
> 
> [...]
> I don't think this has been a deliberated choice. Support for date_fmt
> (which is a GNU extension), has been added back in 2000 in commit
> d8337213c8. At that time all locales got date_fmt set to the default
> setting, and later locales got this value updated through the years.
> This has never been done for the US locale. Then in commit 2e7a461328
> all locales with the default value got this field removed.

Thank you for this research.  There are many locales which don't have
date_fmt defined which means they use the default value from C locale:
"%a %b %e %H:%M:%S %Z %Y".  This is bad for many of them because this
assumes the date order is MDY which is not the most popular order
around the world.  I did not yet have time to file a bug report and/or
fix it, anybody feel free to do it.

> [...]
> > I wonder whether our users expect such a change.
> 
> At least a few users, but I agree it's difficult to know for the
> majority of users.

I think we had sufficient confirmations here.

Regards,

Rafal
Aurelien Jarno - Jan. 2, 2019, 5:41 p.m.
On 2018-12-31 19:16, Rafal Luzynski wrote:
> 31.12.2018 12:07 Aurelien Jarno <aurelien@aurel32.net> wrote:
> > 
> > [...]
> > I don't think this has been a deliberated choice. Support for date_fmt
> > (which is a GNU extension), has been added back in 2000 in commit
> > d8337213c8. At that time all locales got date_fmt set to the default
> > setting, and later locales got this value updated through the years.
> > This has never been done for the US locale. Then in commit 2e7a461328
> > all locales with the default value got this field removed.
> 
> Thank you for this research.  There are many locales which don't have
> date_fmt defined which means they use the default value from C locale:
> "%a %b %e %H:%M:%S %Z %Y".  This is bad for many of them because this
> assumes the date order is MDY which is not the most popular order

By looking at the difference between d_t_fmt and date_fmt in the locales
having both, it seems to me that the later has been added to display the
full date and time, including the timezone. Indeed for countries that
only span a single timezone, it is usually not displayed.

I have added Jim Meyering in Cc: who have done commit 5ca6863e97 on the
coreutils side, so that the can confirm about that. If he stills
remember of course, as the commit has been done more than 18 years
ago...

> around the world.  I did not yet have time to file a bug report and/or
> fix it, anybody feel free to do it.

I have just opened BZ 24054 about that.

> > [...]
> > > I wonder whether our users expect such a change.
> > 
> > At least a few users, but I agree it's difficult to know for the
> > majority of users.
> 
> I think we had sufficient confirmations here.

Given we are now in freeze period and given the patch has been posted
only recently in a period with many people away from their computer, I
think it's better to wait a bit to give the chance for other people to
comment. After all it has been like that for more than 18 years, so we
can wait a few weeks more. I'll repost this patch once glibc 2.29 has
been released.

Regards,
Aurelien
Paul Eggert - Jan. 2, 2019, 8:20 p.m.
Aurelien Jarno wrote:
> I have added Jim Meyering in Cc: who have done commit 5ca6863e97 on the
> coreutils side, so that the can confirm about that. If he stills
> remember of course, as the commit has been done more than 18 years
> ago...

That's so long ago that it's not in the GNU mailing list archives. However, as I 
vaguely recall, Jim and I worked together on this, and the idea was that the 
output of plain 'date' should be locale-dependent, that there was a mechanism to 
do that in Solaris even though it was not in POSIX, and that we should use that 
mechanism.  I no longer have access to Solaris 8 (the circa 2000 version), but 
on Solaris 10 in an en_US.ISO8859-1 locale if I run 'TZ=UTC0 date' the output is:

Wednesday, January  2, 2019 08:19:11 PM UTC

so it is indeed using 12-hour time with AM/PM, and with a timezone indication.
Rafal Luzynski - Jan. 2, 2019, 11:23 p.m.
2.01.2019 18:41 Aurelien Jarno <aurelien@aurel32.net> wrote:
> 
> On 2018-12-31 19:16, Rafal Luzynski wrote:
> > 31.12.2018 12:07 Aurelien Jarno <aurelien@aurel32.net> wrote:
> > > 
> [...]
> By looking at the difference between d_t_fmt and date_fmt in the locales
> having both, it seems to me that the later has been added to display the
> full date and time, including the timezone.

I have the same impression looking at the C locale.

> Indeed for countries that
> only span a single timezone, it is usually not displayed.

I didn't think about it as a matter of whether a country spans one or
multiple time zones.  I think that if you are asking about the current
time of your desktop computer then it is in the same time zone as you
no matter how large is your country.  OTOH, if you are asking about the
current time of a remote computer it is not helpful that your country
has only one time zone because the computer may be abroad.  But my
reasoning may be wrong, feel free to disagree.

> [...]
> > around the world.  I did not yet have time to file a bug report and/or
> > fix it, anybody feel free to do it.
> 
> I have just opened BZ 24054 about that.

Thank you.

> [...]
> Given we are now in freeze period and given the patch has been posted
> only recently in a period with many people away from their computer, I
> think it's better to wait a bit to give the chance for other people to
> comment. After all it has been like that for more than 18 years, so we
> can wait a few weeks more. I'll repost this patch once glibc 2.29 has
> been released.

Fair enough.

Regards,

Rafal
Rafal Luzynski - Jan. 2, 2019, 11:43 p.m.
31.12.2018 00:54 Aurelien Jarno <aurelien@aurel32.net> wrote:
> --- 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))
> +date_fmt "%a %d %b %Y %I:%M:%S %p %Z"

I thought about it only now.  For the consistency with d_t_fmt,
could we use this?

    date_fmt "%a %d %b %Y %r %Z"

The output of "%r" is defined by t_fmt_ampm which is "%I:%M:%S %p"
in en_US.

Also, please note that here we are switching from "%a %b %e"
(month-day order) to "%a %d %b" (day-month order).  I hope this
is not confusing for the US citizens, especially since d_t_fmt
already has day-month order and since "%b" cannot be mistaken
for the day number.

en_GB has the day-month order in both date_fmt and d_t_fmt.

Regards,

Rafal
Aurelien Jarno - Jan. 2, 2019, 11:47 p.m.
On 2019-01-03 00:23, Rafal Luzynski wrote:
> 2.01.2019 18:41 Aurelien Jarno <aurelien@aurel32.net> wrote:
> > 
> > On 2018-12-31 19:16, Rafal Luzynski wrote:
> > > 31.12.2018 12:07 Aurelien Jarno <aurelien@aurel32.net> wrote:
> > > > 
> > [...]
> > By looking at the difference between d_t_fmt and date_fmt in the locales
> > having both, it seems to me that the later has been added to display the
> > full date and time, including the timezone.
> 
> I have the same impression looking at the C locale.
> 
> > Indeed for countries that
> > only span a single timezone, it is usually not displayed.
> 
> I didn't think about it as a matter of whether a country spans one or
> multiple time zones.  I think that if you are asking about the current
> time of your desktop computer then it is in the same time zone as you
> no matter how large is your country.  OTOH, if you are asking about the
> current time of a remote computer it is not helpful that your country
> has only one time zone because the computer may be abroad.  But my
> reasoning may be wrong, feel free to disagree.
> 

My point was that country spanning multiple time zones usually (or
should?) already have the time zone indicated in d_t_fmt, so d_t_fmt and
date_fmt should be the same. At least that was my impression looking
only at a few locales.

However after grepping the existing locales, it is not that clear
anymore. The presence of %z or %Z in d_t_fmt seems mostly random. And
often different in t_fmt...

Regards,
Aurelien
Florian Weimer - Jan. 3, 2019, 12:33 p.m.
* Paul Eggert:

> […] I no longer have access to Solaris 8 (the circa 2000 version), but
> on Solaris 10 in an en_US.ISO8859-1 locale if I run 'TZ=UTC0 date' the
> output is:
>
> Wednesday, January  2, 2019 08:19:11 PM UTC
>
> so it is indeed using 12-hour time with AM/PM, and with a timezone
> indication.

Thanks.  This suggests that changing the locale should not cause too
many problems.

Florian
Rafal Luzynski - Jan. 5, 2019, 12:19 a.m.
3.01.2019 00:47 Aurelien Jarno <aurelien@aurel32.net> wrote:
> [...]
> My point was that country spanning multiple time zones usually (or
> should?) already have the time zone indicated in d_t_fmt, so d_t_fmt and
> date_fmt should be the same. At least that was my impression looking
> only at a few locales.
> 
> However after grepping the existing locales, it is not that clear
> anymore. The presence of %z or %Z in d_t_fmt seems mostly random. And
> often different in t_fmt...

I'm not aware of any rule saying whether d_t_fmt should include a time
zone or not.  Additionally, date_fmt is a GNU extension.  But I perceive
the built in C locale as a model implementation.  Other locales may be
pretty sloppy.  In C locale the only difference between d_t_fmt and
date_fmt is that date_fmt contains the time zone while d_t_fmt does not.

So, have we agreed that we can switch date_fmt in en_US to 12 hour
format?  Can we do it now despite the freeze period?  What do you
think about my suggestion to use "%r" instead of "%I:%M:%S %p"?

Regards,

Rafal
Aurelien Jarno - Jan. 5, 2019, 12:39 a.m.
On 2019-01-05 01:19, Rafal Luzynski wrote:
> 3.01.2019 00:47 Aurelien Jarno <aurelien@aurel32.net> wrote:
> > [...]
> > My point was that country spanning multiple time zones usually (or
> > should?) already have the time zone indicated in d_t_fmt, so d_t_fmt and
> > date_fmt should be the same. At least that was my impression looking
> > only at a few locales.
> > 
> > However after grepping the existing locales, it is not that clear
> > anymore. The presence of %z or %Z in d_t_fmt seems mostly random. And
> > often different in t_fmt...
> 
> I'm not aware of any rule saying whether d_t_fmt should include a time
> zone or not.  Additionally, date_fmt is a GNU extension.  But I perceive
> the built in C locale as a model implementation.  Other locales may be
> pretty sloppy.  In C locale the only difference between d_t_fmt and
> date_fmt is that date_fmt contains the time zone while d_t_fmt does not.

Yes, I agree that there is no rule, and that probably explains while
there are so many variants. Usually one creates a locale using another
one as an example.

There is at least the case of zh_HK for which t_fmt contains the
time zone, but not d_t_fmt. That looks strange to me.

> So, have we agreed that we can switch date_fmt in en_US to 12 hour
> format?

Personally I am convinced it's the right thing to do.

> Can we do it now despite the freeze period? 

I think it's more a question for Siddhesh.

> What do you
> think about my suggestion to use "%r" instead of "%I:%M:%S %p"?

That's more a technical question. I used this form, because the C locale
expands the conversion specifications. But if we can technically use
"%r", it's fine for me, I can update the patch. Can we even use "%c"
directly?

Regards,
Aurelien
Rafal Luzynski - Jan. 5, 2019, 2:24 p.m.
5.10.2019 01:39 Aurelien Jarno <aurelien@aurel32.net> wrote:
> 
> On 2019-01-05 01:19, Rafal Luzynski wrote:
> [...]
> Yes, I agree that there is no rule, and that probably explains while
> there are so many variants. Usually one creates a locale using another
> one as an example.

I believe this is the case.

> There is at least the case of zh_HK for which t_fmt contains the
> time zone, but not d_t_fmt. That looks strange to me.

I was reworking this recently but I have not changed (added/removed)
anything with the time zones.  It has been for long time as it is now.

> > So, have we agreed that we can switch date_fmt in en_US to 12 hour
> > format?
> 
> Personally I am convinced it's the right thing to do.
> 
> > Can we do it now despite the freeze period? 
> 
> I think it's more a question for Siddhesh.

I'm adding CC: Siddhesh, what do you think?  The patch is not yet
ready but the general idea is to use 12h time format in en_US
instead of 24h.  We have agreed that this is a good idea for US
users, we are only discussing how to implement the format and whether
to do it now or postpone until 2.30.

> > What do you
> > think about my suggestion to use "%r" instead of "%I:%M:%S %p"?
> 
> That's more a technical question. I used this form, because the C locale
> expands the conversion specifications. But if we can technically use
> "%r", it's fine for me, I can update the patch. Can we even use "%c"
> directly?

I think I have not seen "%c" in any locale but I'm not aware of any
technical limitation.  Does it make any difference, like a performance
drop?  Probably yes and probably negligible.  Please test thoroughly
and please post here before committing so other people will be able
to test as well.

Thank you and regards,

Rafal
Aurelien Jarno - Jan. 6, 2019, 5:19 p.m.
On 2019-01-05 15:24, Rafal Luzynski wrote:
> 5.10.2019 01:39 Aurelien Jarno <aurelien@aurel32.net> wrote:
> > 
> > On 2019-01-05 01:19, Rafal Luzynski wrote:
> [...]
> > > What do you
> > > think about my suggestion to use "%r" instead of "%I:%M:%S %p"?
> > 
> > That's more a technical question. I used this form, because the C locale
> > expands the conversion specifications. But if we can technically use
> > "%r", it's fine for me, I can update the patch. Can we even use "%c"
> > directly?
> 
> I think I have not seen "%c" in any locale but I'm not aware of any
> technical limitation.  Does it make any difference, like a performance
> drop?  Probably yes and probably negligible.  Please test thoroughly

I have tried using "%c" and it works fine on my system. That said, given
no other locales use this, I am a bit reluctant to do that change now.

> and please post here before committing so other people will be able
> to test as well.

I have just posted an updated version of the patch, which sticks to
"%a %d %b %Y %r %Z" and has and update comment. I have tested it here
and I have also checked it doesn't cause any regression in the
testsuite, as the en_US locale is used in a few tests.

Regards,
Aurelien
Siddhesh Poyarekar - Jan. 7, 2019, 8:06 a.m.
On 05/01/19 7:54 PM, Rafal Luzynski wrote:
> I'm adding CC: Siddhesh, what do you think?  The patch is not yet
> ready but the general idea is to use 12h time format in en_US
> instead of 24h.  We have agreed that this is a good idea for US
> users, we are only discussing how to implement the format and whether
> to do it now or postpone until 2.30.

OK for 2.29.

Siddhesh
Rafal Luzynski - Jan. 7, 2019, 10:58 a.m.
6.01.2019 18:19 Aurelien Jarno <aurelien@aurel32.net> wrote:
> [...]
> I have tried using "%c" and it works fine on my system. That said, given
> no other locales use this, I am a bit reluctant to do that change now.

I totally agree with that.

Regards,

Rafal

Patch

diff --git a/ChangeLog b/ChangeLog
index a2170167c7..8f90d99290 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,8 @@ 
+2018-12-31  Aurelien Jarno  <aurelien@aurel32.net>
+
+	[BZ #24046]
+	* localedata/locales/en_US (date_fmt): Define.
+
 2018-12-28  Justus Winter <4winter@informatik.uni-hamburg.de>
 
 	* hurd/lookup-retry: Include <unistd.h>.
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))
+date_fmt "%a %d %b %Y %I:%M:%S %p %Z"
+%
 % Strings for AM/PM
 %
 am_pm	"AM";"PM"