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 [email protected] http://aurel32.net
