Closed Bug 1429578 Opened 7 years ago Closed 4 years ago

Firefox No Longer Honors LC_TIME When Printing Date

Categories

(Core :: Internationalization, defect, P4)

Product:
Core
Component:
Internationalization
Version:
57 Branch
Type:
defect

Tracking

()

Status:
VERIFIED WONTFIX

People

(Reporter: ormos-ffb18, Unassigned)

References

Details

Attachments

(1 file)

Screenshot excerpts showing file:///etc/ from FF52 and FF58
44.47 KB, image/png
Details 
User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Firefox/52.0
Build ID: 20170802111520

Steps to reproduce:

1. Unset environment variable LC_ALL.

2. Set environment variable LC_TIME to "en_DK.iso88591".

3. Visit a web page.

4. Enter Control-P to open the print dialog.

5. Select the Options tab.

6. Inspect the Header and Footer section to verify that Date/Time appears, e.g., as one of the footer elements.

7. Click on the print button.




Actual results:

Footer of printed output has a date in a format different from that specified by locale en_DK.iso88591.  E.g., 1/10/18 .


Expected results:

Printed output has a date in the format specified by locale en_DK.iso88591. E.g. 2018-01-10 .

This was working as expected in version 52.
The bug tracker recorded the version of the browser I was using when I reported the bug. 

To clarify, I observed the bug when running the following versions (of which the second-listed is a Beta):

Mozilla/5.0 (X11; Linux x86_64; rv:57.0) Gecko/20100101 Firefox/57.0
buildID;20180103231032

Mozilla/5.0 (X11; Linux x86_64; rv:58.0) Gecko/20100101 Firefox/58.0
buildID;20180103230655
LC_TIME won't be used until bug 1409158 is fixed.  Can file:///etc/ show expected date format on Firefox 58+?
Flags: needinfo?(ormos-ffb18)
Component: Untriaged → Internationalization
Product: Firefox → Core
Response to Makoto Kato's question, "Can file:///etc/ show expected date format on Firefox 58+?", attached are screenshot excerpts showing file:///etc/ from FF52, showing correct behavior, and FF58, showing incorrect behavior.
Flags: needinfo?(ormos-ffb18)
(In reply to Makoto Kato [:m_kato] from comment #2)
> LC_TIME won't be used until bug 1409158 is fixed.  Can file:///etc/ show
> expected date format on Firefox 58+?

No. When file:///etc/ is displayed in Firefox 58, the dates are not shown in the expected date format (i.e., that defined by the "en_DK.iso88591" locale).
Priority: -- → P3
The buggy behavior persists in Firefox 60.0.2.
Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Firefox/60.0
buildID;20180605171542

As of 2019/06/17, about 17 months after the initial report, the buggy behavior persists in:

Mozilla Firefox 67.0.2 BuildID=20190607204818

and

Mozilla Firefox 68.0b10 BuildID=20190613141208

it would be great for someone to debug why the code in [0] doesnt work for this particular user.

Neil: can you paste your Internationalization second in about:support?

Marking this as good-first-bug since it should be trivial for someone with basic C++ skills to refactor the code in any way necessary to fix it. Also P4, since it's likely a result of uncommon setup.

[0] https://searchfox.org/mozilla-central/source/intl/locale/gtk/OSPreferences_gtk.cpp#36

Keywords: good-first-bug
Priority: P3 → P4

(In reply to Zibi Braniecki [:zbraniecki][:gandalf] from comment #7)

Neil: can you paste your Internationalization second in about:support?

Internationalization & Localization

Application Settings
Requested Locales: ["en-US"]
Available Locales: ["en-US"]
App Locales: ["en-US"]
Regional Preferences: ["en-DK"]
Default Locale: "en-US"
Operating System
System Locales: ["en-US"]
Regional Preferences: ["en-DK"]

(In reply to Zibi Braniecki [:zbraniecki][:gandalf] from comment #7)

[...] Also P4, since it's likely a result of uncommon setup.

What specifically is likely to be uncommon about my setup?

What specifically is likely to be uncommon about my setup?

You're looking to use regional preferences locale that differs from your app UI locale. That's pretty uncommon.

Your UI locale is "en-US" and your regional preferences are "en-DK". That seems to match your request from LC_TIME normalized to Unicode Locale Identifiers.

This is how Unicode CLDR formats en-DK:

(new Date()).toLocaleString("en-DK");
"17/06/2019, 16.41.49"

It seems to me that this is the correct formatting for your requested locale. If you think this is not the correct date time format for en-DK, you may have to request change to CLDR database - http://cldr.unicode.org/index/bug-reports

On my system, locales are "compiled" from locale definition files residing in /usr/share/i18n/locales/.

In /usr/share/i18n/locales/en_DK, the LC_TIME stanza includes these definitions [*]:

%% date formats following ISO 8601-1988
d_t_fmt "%Y-%m-%dT%T %Z"
d_fmt "%Y-%m-%d"
t_fmt "%T"

When a locale is set via an environment variable (e.g., LC_ALL or LC_TIME), users reasonably expect that locale-aware programs will follow the definitions in the corresponding locale definition files. Firefox version 52.0.9 and prior match the definition in the en_DK locale file.

[*] Converted into readable characters.

However, I'm not particularly wedded to LC_TIME=en_DK. I just want dates formatted as %Y-%m-%d without changing the UI language. The en_DK locale has been a way to do that in the past.

(In reply to Neil Ormos from comment #11)

Firefox version 52.0.9 and prior match the definition in the en_DK locale file.

I phrased that inartfully. I meant to say that when the en_DK local is set via LC_ALL or LC_TIME, the date and time formatting behavior of Firefox version 52.0.9 (and prior versions) matches the definition set in the en_DK locale definition file.

users reasonably expect that locale-aware programs will follow the definitions in the corresponding locale definition files. Firefox version 52.0.9 and prior match the definition in the en_DK locale file.

Right, that's a POSIX model which we moved away from. Gecko is currently using Unicode project based CLDR/ICU model of internationalization. It has a lot of adventages over POSIX and for majority of users the shortcomings are invisible. Unfortunately for users who utilized the customize values in POSIX, that switch is noticable.

I don't believe we'll ever revert that change, but the good news is that it seems that glibc is planning to integrate CLDR as well, which should at least unify the experience.

I just want dates formatted as %Y-%m-%d without changing the UI language. The en_DK locale has been a way to do that in the past.

Understood. I think you may want to find a locale in CLDR that matches that pattern then. Alternatively, I'd be open to allow Gecko to handle hardcoded datetime formats as overrides to CLDR backed model. If you want to contribute a patch, I'll review it.

This may also be a dupe of bug 1426907 - there are more people who want their date to be formatted this way. It would be nice to see those users rally and contribute :)

This is not an as uncommon setup as one would think, many IT-workers in european minority language countries, (scandinavian/slavic esp.) actually prefers to use english language as their primary language because it makes it easier to refer to reference documentation which are more plentifully available in english

Gecko now allows people to override their date/time patterns since bug 1426907.

Thunderbird or Firefox may add it to Preferences (bug 1509096).

We're not going to honor POSIX overrides again

Status: UNCONFIRMED → RESOLVED
Closed: 4 years ago
Resolution: --- → WONTFIX

I tried inserting the date/time patterns listed at

https://bugzilla.mozilla.org/show_bug.cgi?id=1426907#c183

into prefs.js

and those strings appear in the list in about:config.

However, the date format has not changed. Is there something else I need to do?

Version 82.0.3
Build ID 20201108180448

Status: RESOLVED → VERIFIED

However, the date format has not changed. Is there something else I need to do?

Can you add where did you expect to appear? (what UI screen)

Version 82.0.3

This has been fixed after 82 release. Please, test in Nightly or wait for 84 release.

Responsive to comment 19, I was expecting to see dates as specified in the file patterns on a file:/// URL referencing a directory.

Responsive to comment 20, thank you for the reply. Could you please advise in which version the change was made so I won't try to test with a version that lacks the change?

Also, I could not figure out how to reopen this closed bug and it was not clear to me whether my follow-up question on a "closed" bug would ever be seen, so I cloned the bug as https://bugzilla.mozilla.org/show_bug.cgi?id=1678139

Should I take some action to withdraw that report?

Also, could you please give me the name of the override preference for the connector mentioned here:
https://bugzilla.mozilla.org/show_bug.cgi?id=1674212

and here:

https://bugzilla.mozilla.org/show_bug.cgi?id=1426907#c185

Is it

intl.date_time.pattern_override.date_time_short

and does a value of "{1} {0}" cause the assembly of the final date/time string to consist of the date followed by the time, separated by a blank?

Also, are there no equivalent overrides including the connector for the medium, long, and full versions of the combined date-time string?

Thank you.

(In reply to Zibi Braniecki [:zbraniecki][:gandalf] from comment #20)

Version 82.0.3

This has been fixed after 82 release. Please, test in Nightly or wait for 84 release.

Thank you for the help. It appears to work in Version 84.0b2 Build ID 20201117192430

You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: