Bug#877900: general: en-us locale defaults to 24-hour "military" time on stock install

2017-10-07 Thread Adam Borowski
On Sat, Oct 07, 2017 at 01:47:30PM -0700, Steve Langasek wrote:
> On Sat, Oct 07, 2017 at 07:17:56AM +0200, Adam Borowski wrote:
> > Obviously, this is an abuse, but that's the cost of being the default.  If
> > we had C.UTF-8 as a first-class locale, this wouldn't be that much an
> > argument, but currently d-i falls back to en_US for English for most
> > countries.
> 
> > The decision belongs to the maintainer (I'm reassigning), but per the above
> > reasoning, I expect wontfix.
> 
> 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.

This is what d-i does, thus such overloading is really widespread at
present.  I'm not claiming this is a good idea, merely describing status
quo.  A thoughtless change would risk breaking systems that rely on times
being sortable, fitting within current field width, etc.

> There's also no reason to believe that's actually what has happened here.
> 
> C.UTF-8 *is* a first-class locale, and if any installers are using
> en_US.UTF-8 when they should use C.UTF-8, those installers must be fixed.

d-i allows selecting C as locale, but that's real 7-bit C rather than
C.UTF-8.  As such, it's not really usable in most contexts.

Furthermore, if your location is not UK, Ireland or a few others, d-i will
default to en_US.UTF-8.

> Furthermore, the only bug I'm aware of in this area is the fact that, when
> no locale is configured in the environment, glibc falls back to C instead of
> to C.UTF-8, despite the fact that this is shipped prebuilt in the libc
> package and is always available.

I agree here, that would be the natural thing to do.  I've even submitted a
patch implementing this (#874160), however it hasn't been accepted as the
maintainer doesn't want a divergence with upstream.  Upstream glibc already
has a proposal with this change -- I've tried contacting its proposer but
did not receive an answer.  I don't know glibc upstream's politics well
enough to drive it forward.

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

You should have considering this before invading! :p


Meow.
-- 
⢀⣴⠾⠻⢶⣦⠀ We domesticated dogs 36000 years ago; together we chased
⣾⠁⢰⠒⠀⣿⡁ animals, hung out and licked or scratched our private parts.
⢿⡄⠘⠷⠚⠋⠀ Cats domesticated us 9500 years ago, and immediately we got
⠈⠳⣄ agriculture, towns then cities. -- whitroth on /.



Bug#877900: general: en-us locale defaults to 24-hour "military" time on stock install

2017-10-07 Thread Steve Langasek
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)



> Obviously, this is an abuse, but that's the cost of being the default.  If
> we had C.UTF-8 as a first-class locale, this wouldn't be that much an
> argument, but currently d-i falls back to en_US for English for most
> countries.

> The decision belongs to the maintainer (I'm reassigning), but per the above
> reasoning, I expect wontfix.

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.

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

C.UTF-8 *is* a first-class locale, and if any installers are using
en_US.UTF-8 when they should use C.UTF-8, those installers must be fixed.

Furthermore, the only bug I'm aware of in this area is the fact that, when
no locale is configured in the environment, glibc falls back to C instead of
to C.UTF-8, despite the fact that this is shipped prebuilt in the libc
package and is always available.


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.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


signature.asc
Description: PGP signature