1935895 - Date not formatted according to user's locale (LC_TIME)

Status: UNCONFIRMED

(Core :: Internationalization, defect, P3)

Description

[lists]

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:133.0) Gecko/20100101 Firefox/133.0

Steps to reproduce:

Many pages show the wrong date format. My system's locale is set to ISO8601 (en-DK) and the date command confirms this:
$ date
2024-12-08T15:13:20 CET

$ locale -ck date_fmt
LC_TIME
date_fmt="%Y-%m-%dT%T %Z"

The browser language is set to English (GB). But that's not what should control the date formatting. And “Use your operating system settings for “English (Denmark)” to format dates, times, numbers, and measurements.” is also selected. So this confirms, that Firefox has picked up the correct TC_TIME format setting to format the date (en-DK = English (Denmark)).

Actual results:

Pages show the date in DD/MM/YYYY format instead of YYYY-MM-DD.

Expected results:

The date should be formatted as YYYY-MM-DD. For instance:
https://www.w3schools.com/jsref/tryit.asp?filename=tryjsref_tolocalestring
→
toLocaleString() returns a date as a string, using locale settings:

08/12/2024, 15.03.56

Comment 1

[BugBot [:suhaib / :marco/ :calixte]]

The Bugbug bot thinks this bug should belong to the 'Core::Internationalization' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Comment 2

[BugBot [:suhaib / :marco/ :calixte]]

The severity field is not set for this bug.
:m_kato, could you have a look please?

For more information, please visit BugBot documentation.

Comment 3

[Makoto Kato [:m_kato]]

Could you attach about:support?

Comment 4

[lists]

Attachment: ff_about_support

Comment 5

[[:mirabilos]]

Same happens to me, with the latest ESR on Debian, but this is very likely not build-specific.

I’ve set LANG=C.UTF-8 (and LC_CTYPE=C.UTF-8 explicitly, but that’s ignored) and no other locale-related environment variables are set. I get annoyed about AM/PM and see if I can improve the situation. I read that Firefox ignores LC_TIME, but apparently that got half-arsed fixed in the meantime: it seems to scan LC_TIME but then do its own thing.

If I set LC_TIME=de_DE.UTF-8 then new Date().toLocaleTimeString(); DTRT but new Intl.DateTimeFormat().format(new Date()); mistakenly outputs 1.2.2025 instead of the correct 01.02.2025 ☹

Even worse, if I set LC_TIME=de_DE.UTF-8@iso8601 (a custom locale) it still outputs 1.2.2025 ipv the correct 2025-02-01 ☹☹☹

Comment 6

[[:mirabilos]]

Reading the linked bug, that definitely plays a role here as well. I have set Firefox to British English, as I dislike translated software (the translation quality is generally bad) but do very much NOT want american datetimes. Ideally, I want ISO 8601, which I get via my custom LC_TIME (which Firefox ignores… the locale itself, not the LC_TIME environment string).

Comment 7

[Makoto Kato [:m_kato]]

Actually we are using application locale (You know, bug 1739712 is more detail), but intl.regional_prefs.use_os_locales=true by about:config uses OS locale instead.

Comment 8

[[:mirabilos]]

It’s true for me, but at least 128ESR does not use the OS locale.

$ locale -k LC_TIME
abday="So;Mo;Di;Mi;Do;Fr;Sa"
day="Sonntag;Montag;Dienstag;Mittwoch;Donnerstag;Freitag;Samstag"
abmon="Jan;Feb;Mrz;Apr;Mai;Jun;Jul;Aug;Sep;Okt;Nov;Dez"
mon="Januar;Februar;März;April;Mai;Juni;Juli;August;September;Oktober;November;Dezember"
am_pm=";"
d_t_fmt="%04Y-%m-%dT%H:%M:%S%z (%Z), %04G-W%V-%u (%a)"
d_fmt="%04Y-%m-%d"
t_fmt="%H:%M:%S"
t_fmt_ampm=""
era="+:1:0001/01/01:+*:n.u.Z.:%-Ey %EC";"+:1:0000/12/31:-*:v.u.Z.:%-Ey %EC"
era_year=""
era_d_fmt="%-d. %B %EY"
alt_digits=
era_d_t_fmt="%A, %-d. %B %EY, %H:%M:%S %Z"
era_t_fmt="%H:%M:%S"
time-era-num-entries=2
time-era-entries="+"
week-ndays=7
week-1stday=19971130
week-1stweek=4
first_weekday=2
first_workday=2
cal_direction=1
timezone=""
date_fmt="%A, %-d. %B %Y, %H:%M:%S %Z"
time-codeset="UTF-8"
alt_mon="Januar;Februar;März;April;Mai;Juni;Juli;August;September;Oktober;November;Dezember"
ab_alt_mon="Jan;Feb;Mär;Apr;Mai;Jun;Jul;Aug;Sep;Okt;Nov;Dez"

But:

» new Intl.DateTimeFormat().format(new Date())
← "4.2.2025"

So this uses something broken (not even correct for the stock de_DE.UTF-8 locale), which is specific to Firefox (as it doesn’t show up in the locale data).

Comment 9

[[:mirabilos]]

I’ve been looking through that JS object, but this is not very helpful:

» new Intl.DateTimeFormat().resolvedOptions()
← ‣ Object { locale: "de-DE", calendar: "gregory", numberingSystem: "latn", timeZone: "Europe/Berlin", year: "numeric", month: "numeric", day: "numeric" }

Notably, my LC_TIME locale string is not just de-DE but de_DE.UTF-8@iso8601, and it really ought to be using the strings contained in the locale to format the data.

Can we somehow check its internal properties, looking at the source I see it could be interesting?

I have searched through the source tree and have a vague guess that it uses the CLDR data through ICU, as that says…

        gregorian{
            availableFormats{
                yMd{"d.M.y"}  

… which notably doesn’t say dd.MM.yyyy (this is only a wild guess, but given that the JS/C++ impl calls TryFormat, which a quick grep points out is an ICU routine, at least not wholly unsubstantiated).

“Using the locale” basically means to setlocale(LC_ALL, ""); and then use e.g. strftime(buf, len, "%x", tm); (or nl_langinfo or somesuch). Everything else does not use the locale as is configured on a POSIX-ish system.

Comment 10

[André Bargull [:anba]]

(In reply to [:mirabilos] from comment #9)

Notably, my LC_TIME locale string is not just de-DE but de_DE.UTF-8@iso8601, [...]

OSPreferences::ReadRegionalPrefsLocales reads LC_TIME, the locale id is first passed to OSPreferences::CanonicalizeLanguageTag and then to LocaleService::CanonicalizeLanguageId. This then calls unic_langid_canonicalize, which finally calls new_langid_for_mozilla. And new_langid_for_mozilla removes any contents of the '.' character.

Anything after the '.' character is removed, because the locale parser doesn't support the codeset or modifier parameters. But even if modifier parameters were supported and translated to the corresponding BCP-47 Unicode extension, then it's still not possible to use de-DE-u-ca-iso8601 as the default locale, because that's not supported by ECMA-402. From https://tc39.es/ecma402/#sec-defaultlocale:

It must not contain a Unicode locale extension sequence.

Comment 11

[[:mirabilos]]

OSPreferences::ReadRegionalPrefsLocales reads LC_TIME, the locale id is […]

But that’s not my locale. That’s just the string POSIX uses to determine which locale to load. The locale is contained in (in my example) /usr/lib/locale/locale-archive in binary form.

As a user, I’m interested in using the exact locale I configured in the operating system, I have no deal with ECMA or something.

---

But even if we use the stock de_DE.UTF-8 locale, the date format representation is still wrong, as the leading zeroes are missing (“d.M.yyyy” or “d.M.y”), and they are mandatory for the legacy short form (“dd.MM.yyyy”, as opposed to the “d. MMMM yyyy” long form, or the “yyyy-MM-dd” modern short form).

Comment 12

[[:mirabilos]]

Attachment: locale on windows

Same on 135 on Windows. Set up the locale as necessary, switched the preference to use the OS locale to true, restarted Firefox (which was necessary to get the update to 135 anzwaz), and it still shows me 4.2.2025 in JS.

Comment 13

[Pedro]

Same issue here, Firefox is not honoring the time settings of my locale. Dates are being shown in the US format instead of the format configured in my LC_TIME (e.g., it's showing 5/14/2025 instead of 14/5/2025).

$ locale
LANG=en_US.UTF-8
LANGUAGE=en_US
LC_CTYPE=pt_PT.UTF-8
LC_NUMERIC=pt_PT.UTF-8
LC_TIME=pt_PT.UTF-8
LC_COLLATE="en_US.UTF-8"
LC_MONETARY=pt_PT.UTF-8
LC_MESSAGES="en_US.UTF-8"
LC_PAPER=pt_PT.UTF-8
LC_NAME=pt_PT.UTF-8
LC_ADDRESS=pt_PT.UTF-8
LC_TELEPHONE=pt_PT.UTF-8
LC_MEASUREMENT=pt_PT.UTF-8
LC_IDENTIFICATION=pt_PT.UTF-8
LC_ALL=