Bug#1121994: en_CA locale incorrectly uses AM/PM time formats, should follow en_GB
Hi,
On 2025-12-05 11:55, Antoine Beaupre wrote:
> Package: locales
> Version: 2.41-12
> Severity: normal
> Tags: l10n
>
> I am perhaps completely confused about this, but it seems to me the
> time format in libc is incorrect, as far as "time in Canada" is
> concerned:
>
> anarcat@angela:~> LC_TIME=en_CA date
> Fri 05 Dec 2025 11:30:46 AM EST
> anarcat@angela:~> LC_TIME=en_US date
> Fri Dec 5 11:30:49 AM EST 2025
> anarcat@angela:~> LC_TIME=fr_FR date
> ven. 05 d. 2025 11:30:56 EST
> anarcat@angela:~> LC_TIME=en_OMGWTF date
> Fri Dec 5 11:31:02 EST 2025
>
> In the above, you can see the en_CA locale uses an AM/PM suffix like
> en_US, while fr_FR (and a non-existent en_OMGWTF locale) do not have
> that suffix, so correctly show 24h times.
Yes, that matches what is in the locale data [1]. Note however that the
fr_CA locale uses the 24h time format [2].
> I believe this is incorrect.
>
> According to Wikipedia[1]
>
> > The Government of Canada recommends using the 24-hour clock to avoid
> > ambiguity, and many industries require it. [...] The 24-hour clock
> > is widely used in contexts such as transportation, medicine,
> > environmental services, and data transmission, "preferable for
> > greater precision and maximum comprehension the world over". Its use
> > is mandatory in parts of the government as an element of the Federal
> > Identity Program, especially in contexts such as signage where
> > speakers of both English and French read the same text.
>
> That said, Wikipedia also says:
>
> > Outside the influence of government style, the 24-hour system is
> > rarely used. The government describes the 24-hour system as
> > "desirable" but does not enforce its use, meaning that the 12-hour
> > clock remains common for oral and informal usage in English-speaking
> > contexts. It is not the recommended style in journalism, for
> > example.
For a country like Canada, is there any variation between the
French-speaking and English-speaking regions, independently of the
language used? I mean is there any variation between Montreal and
Vancouver for instance?
> So that might seem to indicate that we should *not* fix this and keep
> the AM/PM format, except Wikipedia *also* says that:
>
> > This situation is similar to the use of the 24-hour clock in the
> > United Kingdom.
>
> [1]: https://en.wikipedia.org/wiki/Date_and_time_notation_in_Canada
>
> But then if you look at the en_GB locale, *that* uses 24h time
> formats:
>
> anarcat@angela:~> LC_TIME=en_UK date
> Fri Dec 5 11:44:05 EST 2025
>
> So, there's some inconsistency here. I think en_CA, being a british
> colony and still somewhat part of the british empire (and,
> technically, a dominion of the defunct Queen of Canada, Elizabeth II),
> should follow en_GB on that extremely narrow example.
>
> For context, I live in Montreal, Canada, and I prefer 24h times on my
> systems. I am a native French speaker, but am fully fluent in English
> and I've worked most of adult life in English. I've been working in
> computer science for decades at this point and have been involve in
> the earlier days of the GNU gettext project for french translations, I
> think I'm fairly well attuned with the overall "i18n" / "l10n" effort,
> even though I have somewhat given up on that utopia a while back.
>
> In my day job, I communicate with people all over the world who use
> 24h time formats. In fact, 24h time formats make it *much* easier for
> me to schedule meetings with other folks around the world, in
> different timezones, as you can simply compute times with a single 24
> modulo instead of two 12 modulus.
>
> At home, I *will* certainly say things like "it's three o'clock" (with
> "PM" being implicit), but I certainly prefer to *see* my clocks say
> "15:00". I know it's bizarre, but I find it just completely nuts and
> jarring to see *computers* try to talk like humans. There's context in
> human language, and it's fine if people say "three o'clock" and not
> "fifteen o'clock", that would be bonkers, we know what "three" means
> in the context of the day.
>
> But for time, in computers, using "3:00 PM" is just baroque and
> weird. It feels like we're back under queen victoria and I should be
> shoving coal in my computer to get it faster into the next millenium
> so it can start speaking proper english already.
>
> I originally investigated this as part of what I thought was a bug in
> Nextcloud, a web application that supports calendar features, where
> the date picker because weird at some point. At first, I thought the
> issue was with Nextcloud, and discussed the problem in this issue:
>
> https://github.com/nextcloud/calendar/issues/6359
>
> ... then I thought it was in Firefox, and found *that* issue:
>
> https://bugzilla.mozilla.org/show_bug.cgi?id=1532923
>
> But now, I can reproduce the problem all the way down to date(1),
> which is part of coreutils so, technically, the bug could be filed
> there, but I'd be surprised if the issue was *not* in locales (and
> therefore glibc) at this point.
Yes, as said above this matches the current locale data [1], so that's
why many software are showing the time in AM/PM format.
While this can be fixed in a Debian specific, experience shows that
diverging between distribution is just causing more issues. For instance
some testsuite might test output for the en_CA locale against an
expected output, and having difference between distributions just means
that we need to fix that in Debian specific patch. Therefore I think
this needs to be brought upstream first.
You already provided a good explanation about why this should be
changed, do you mind reporting that in the upstream BTS [3]?
Alternatively I can do the proxy, but doing so might be difficult in
case the discussion gets long. Once there is an agreement, I don't mind
submitting the corresponding patch for review on the mailing list.
Regards
Aurelien
[1] https://sourceware.org/git/?p=glibc.git;a=blob;f=localedata/locales/en_CA;h=ca8ac5813abe293bd4a4c730af96d3a512f52539;hb=HEAD#l119
[2] https://sourceware.org/git/?p=glibc.git;a=blob;f=localedata/locales/fr_CA;h=93cd0c4c8838b3361bdc8d1c503628c3526f7540;hb=HEAD#l115
[3] https://sourceware.org/bugzilla/
--
Aurelien Jarno GPG: 4096R/1DDD8C9B
aurelien@aurel32.net http://aurel32.net
Reply to: