[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Bug#877900: How to get 24-hour time on en_US.UTF-8 locale now?



iso_en ?  That sounds smart...

English for most of the world that aren't necessarily native English speakers? https://en.wikipedia.org/wiki/International_English
Use ISO dates and stuff, and pick a random spelling. As a Canadian, I'm pretty sure about colour, but unclear about whether we should standardize on disc. Dates should be iso, even better if it used UTC as the timezone.   This would be a default that would include US keyboard bindings (by default.)
as the easiest thing to default to during installation, etc.. but perhaps I should be disqualified, being both a unix greybeard, and a recovering ntp admin.


On Thu, Feb 7, 2019 at 8:06 AM Adam Borowski <kilobyte@angband.pl> wrote:
On Thu, Feb 07, 2019 at 02:55:33PM +0500, Roman Mamedov wrote:
> So for those of us (the entire world), who have been relying on this behavior:
>
> > * en_US (.UTF-8) is used as the default English locale for all places that
> >   don't have a specific variant (and often even then).  Generally, technical
> >   users use English as a system locale
>
> How do we roll-back what you have done here, and still get en_US.UTF-8 while
> retaining the proper 24-hour time?

> dpkg-reconfigure locales does not list "C.UTF-8" in the main "locales to
> generate" list, but does offer it on the next screen as "Default locale for the
> system environment". After selecting it, we get:
>
> # locale
> LANG=C.UTF-8
> LANGUAGE=
> LC_TIME="en_US.UTF-8"
> LC_ALL=en_US.UTF-8
>
> But still:
>
> # date
> Thu 07 Feb 2019 09:53:47 AM UTC

The root of this issue is worth raising on debian-devel:

The en_US.UTF-8 locale has two purposes:
• a locale for a silly country with weird customs (such as time going in
  four discontinuous segments during the day, writing date in a
  middle-endian format, an unit being shorter on land than surveyed but
  longer than that in the  air, or another unit changing when measuring wet
  vs dry vs slightly moist things)
• base locale for the most of the world save for a few places (UK, AU, ...)
  that have their specific locale -- and often even they use en_US for
  consistency reasons.


So I wonder what would be the best solution?  I can think of:
• promoting C.UTF-8 in our user interfaces (allowing to select it in d-i,
  making dpkg-reconfigure locales DTRT, making it the d-i default)
  -- nice for Unix greybeards, but some users might want case-insensitive
     sort, etc
• inventing a new locale "en" without a country bias
  -- good in the long term but problematic a month before freeze
  -- could be good to have it anyway but not use it until after buster
• ask glibc maintainers to revert the cherry-pick in #877900 for buster,
  then pick a long-term solution


One particular regression caused by this change is sorting no longer
working: "12:01am" "1:01am" "12:01pm" "1:01pm" will be ordered wrong.

On one hand, leftpondians may be entitled to their own locale.  On the
other, let's punish the bastards for imperialism and imposing their own
settings on the rest of the world. :p


Meow!
--
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Remember, the S in "IoT" stands for Security, while P stands
⢿⡄⠘⠷⠚⠋⠀ for Privacy.
⠈⠳⣄⠀⠀⠀⠀


Reply to: