GitLab failing to respect my browser locale (fr-CA)

Everyone can contribute. Help move this issue forward while earning points, leveling up and collecting rewards.

Summary

GitLab fails to render dates properly in my browser locale (fr-CA).

Steps to reproduce

  1. in Firefox, go into Settings -> Language -> Choose your preferred language for displaying pages (Choose...)
  2. "Select languages to add..." and select "French (Canada) [fr-CA]"
  3. reload this issue
  4. mouse-over on a date

It's easier to reproduce if you have relative dates set to "off" because you don't need to mouse-over, but the result is the same.

This also happens when en-CA is selected as the first date, but I later learned that is to be expected.

Example Project

This happens on GitLab.com, in this very issue.

What is the current bug behavior?

The date is rendered with the en-US locale, e.g. 15 Feb 2023, 10:47 a.m.

What is the expected correct behavior?

The dates should be rendered with a fr-CA locale, e.g. 15 Fév 2023, 10:47.

Relevant logs and/or screenshots

Firefox settings:

A screenshot of the Firefox settings showing fr-CA, then en-CA as the first locales

This page rendered with the above settings, showing a.m.:

A screenshot of this issue showing the date on top as Feb 15, 2023, 10:47 a.m.

Output of checks

This bug happens on GitLab.com

Possible fixes

There's a very old issue asking GitLab.com to support 24h date formats, in #15206 (closed). Ideally, users should be able to just select the locale in their preferences, or the date format, without having to change their browser preferences, since that can be a privacy issue.

Furthermore, I strongly believe that GitLab should use a proper, standard, universal date format instead of the horrible date format imposed by the American empire.

This standard is called ISO 8601 and it is used worldwide. To quote Wikipedia:

   On the Internet, the World Wide Web Consortium (W3C) uses the IETF
   standard based on ISO 8601 in defining a profile of the standard
   that restricts the supported date and time formats to reduce the
   chance of error and the complexity of software.

Also:

  The ISO 8601 week date, as of 2006, appeared in its basic form on
  major brand commercial packaging in the United States.

The article goes on documenting 42 different countries, including the United States of America, which have formally adopted ISO 8601 as a national standard (ANSI INCITS 30-1997 (R2008) and NIST FIPS PUB 4-2, specifically, in the US).

See also https://xkcd.com/1179/

So really, I would much rather see GitLab default to ISO than to the garbage dates it sends me now. But failing that, it should at least not fail to detect my locale, especially when it promises it does so in its documentation. It's kind of insulting, in a sense...

It's also possible this can be fixed by enabling the actual locales on the server where the rails app is running, but in my own GitLab Omnibus deployment, we have the locales-all locale and it works fine:

anarcat@gitlab-02:/tmp$ echo $LANG
C.UTF-8
anarcat@gitlab-02:/tmp$ date
Wed Feb 15 15:54:57 UTC 2023
anarcat@gitlab-02:/tmp$ LANG=en_CA.UTF-8 date
Wed 15 Feb 2023 03:55:03 PM UTC
anarcat@gitlab-02:/tmp$ LANG=en_GB.UTF-8 date
Wed 15 Feb 15:55:11 UTC 2023
anarcat@gitlab-02:/tmp$ LANG=fr_CA.UTF-8 date
mer 15 fév 2023 15:55:16 UTC

I was surprised to find out that en_CA actually uses AM/PM (urgh!) which also shows how having a user-accessible setting for choosing how the time is displayed will be more reliable than expecting the user to fix their locale.

Edited by 🤖 GitLab Bot 🤖