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. 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. 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. Thanks, a. -- System Information: Debian Release: 13.2 APT prefers stable-security APT policy: (500, 'stable-security'), (500, 'stable-debug'), (500, 'stable'), (1, 'experimental'), (1, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 6.12.57+deb13-amd64 (SMP w/16 CPU threads; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages locales depends on: ii debconf [debconf-2.0] 1.5.91 ii libc-bin 2.41-12 ii libc-l10n 2.41-12 locales recommends no packages. locales suggests no packages. -- debconf information: * locales/default_environment_locale: en_CA.UTF-8 * locales/locales_to_be_generated: en_CA.UTF-8 UTF-8, en_US.UTF-8 UTF-8
