On 2017-10-07 13:47, Steve Langasek wrote:
> On Sat, Oct 07, 2017 at 07:17:56AM +0200, Adam Borowski wrote:
> > Control: reassign -1 locales
> 
> > On Fri, Oct 06, 2017 at 05:29:20PM -0400, debianuser2017_ wrote:
> > > When Debian 9 is installed with the en-us locale selected, the clock 
> > > defaults
> > > to 24 hour time in the resulting install. This is odd because the normal 
> > > means
> > > of representing the time in the area covered by en-us is to separate the 
> > > day
> > > into two 12-hour segments. (localization issue)

<snip irrelevant C.UTF-8 comments>

> No, this is a nonsense argument.  The en_US.UTF-8 locale must reflect the
> actual usage in the US.  "Well, systems use it as a default, so we're going
> to overload it" would be idiotic.

Totally correct, the locales should reflect the actual usage in a country
and language, which is not always something easy to do and often
controversial.

> There's also no reason to believe that's actually what has happened here.

Now that things have calm down, let's ignore the various hypothesis and
let's look at the code. The two constants from LC_TIME representing the
time, as defined by POSIX and ISO/IEC 14652 are:

- D_T_FMT: String for formatting date and time.
- T_FMT: Time format string.

| $ LC_TIME=en_US.UTF-8 locale -c LC_TIME -k | egrep '^t_fmt=|^d_t_fmt='
| d_t_fmt="%a %d %b %Y %r %Z"
| t_fmt="%r"

In both cases the "%r" format specification is used which correspond to
the time in a.m. or p.m. notation. This two constants correspond in
strftime(3) respectively to the "%c" format specification (The preferred
date and time representation for the current locale) and the "%X" format
specification (The preferred time representation for the current locale
without the date). This can be confirmed with the date utility:

| $ LC_TIME=C.UTF-8 date +%c
| Sun Dec 30 23:21:57 2018
| $ LC_TIME=en_GB.UTF-8 date +%c
| Sun 30 Dec 2018 23:21:57 CET
| $ LC_TIME=en_US.UTF-8 date +%c
| Sun 30 Dec 2018 11:21:57 PM CET
| $ LC_TIME=C.UTF-8 date +%X
| 23:21:57
| $ LC_TIME=en_GB.UTF-8 date +%X
| 23:21:57
| $ LC_TIME=en_US.UTF-8 date +%X
| 11:21:57 PM

In addition to POSIX and ISO/IEC 14652, the GNU libc also defines the 
"date_fmt" constant, which is use by the date(1) utility to display the
date and time. It's an optional field, which defaults to
"%a %b %e %H:%M:%S %Z %Y" if not defined. For what I understand the
goal of this new constant is to always display the timezone, as the
default way of displaying the time usually does not contain it for
countries no spanning multiple time zones.

<snip irrelevant C.UTF-8 comments>
 
> As to the actual bug, I don't know if this represents a deliberate change or
> if it's accidental.  Speaking for myself as an American, I can confirm the
> described behavior... and can say that it completely escaped my notice,
> because I prefer 24h time whenever given the option.  Nevertheless, if this
> bug is to be deemed 'wontfix', it must be done solely with respect to what
> is correct for the *US* locale.

The "date_fmt" constant has been added back in 2000, and the en_US
locale never got it defined. Actually not that many locales define this
constant as the default is often sane. It should only be used by date(1)
so other applications should correctly display the time in 12h format.

For me the proper way to fix this bug would be to define "date_fmt" for
the en_US locale. I don't think this should be controversial given both
"t_fmt" and "d_t_fmt" are already in 12 hours format. I will propose a
patch upstream in that regard, as I prefer to avoid diverging on locales
aspect.

Regards,
Aurelien

-- 
Aurelien Jarno                          GPG: 4096R/1DDD8C9B
aurel...@aurel32.net                 http://www.aurel32.net

Attachment: signature.asc
Description: PGP signature

Reply via email to