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 aurelien@aurel32.net http://www.aurel32.net
Attachment:
signature.asc
Description: PGP signature