1425218 - <input type=time> uses AM/PM on a system with a 24h locale

Status: RESOLVED FIXED

(Core :: Layout: Form Controls, defect, P3)

Description

[Adrian]

User Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:58.0) Gecko/20100101 Firefox/58.0
Build ID: 20171211020921

Steps to reproduce:

- Have your system time format settings set to user the 24h clock, e.g. the default on a German Windows, but regardless of the language the clock may be set to user 12h or 24h format.
- Go to any website that uses `<input type=time>`.


Actual results:

The time picker uses 12h format with AM/PM.


Expected results:

The time picker should use the 24h format since the system is set to use 24h format.
- MS Edge does this
- Chrome has the same bad behavior as Firefox, but changing the browser language (which also results in all browser settings etc to be translated) does affect the format. I did not check if installing a different Firefox language version helps, since I do not want to use a translated Firefox anyway.

Comment 1

[Scott Macpherson]

57 release did not exhibit this behaviour - it appears to have begun with 58. I'll run mozregression for this when I get a chance.

Comment 2

[Scott Macpherson]

15:41.77 INFO: Last good revision: 001d49708a355c9b127fc338722959874cfc7552
15:41.77 INFO: First bad revision: 7abafd0fead900aec67b0de342f71ec856f561cf
15:41.77 INFO: Pushlog:
https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=001d49708a355c9b127fc338722959874cfc7552&tochange=7abafd0fead900aec67b0de342f71ec856f561cf

Comment 3

[Piotr Dobrogost]

The same issue in Chromium was raised at https://bugs.chromium.org/p/chromium/issues/detail?id=263320 6 years ago…

Could we please have any update on this?

Comment 4

[Alice0775 White]

:hsinyi
The bunch of patch of Bug 1366188 seems to cause this problem. Can you please look into this?

Comment 5

[Olli Pettay [:smaug][[e-mail]]]

Not really a regression then, just a bug or behavior or the date/time.

Comment 6

[Zibi Braniecki [:zbraniecki][:gandalf]]

Ok, so here are several things that may come into play:

1. We only use OS locale if the language portion of the locale matches the language portion of Firefox locale by default. That's documented in https://firefox-source-docs.mozilla.org/intl/locale.html#regional-preferences including a preference flag allowing users to override it manually.

You can check what locale we use for regional preferences by going to about:support and looking at the Internationalization section.

2. Assuming we picked the right locales for regional preferences, I'm not sure if <input type="time"> uses the Services.locale.regionalPrefsLocales - if not, it's a bug and it should.

3. Once we have that, we could also use mozIOSPreferences API to identify the correct skeleton/pattern for the time picker. This pattern will take into account manual hourCycle set in the OS on Windows/Gnome/Ubuntu/MacOS/Android. I'm not sure if we're doing it right now, but if we don't, we should.

See https://searchfox.org/mozilla-central/source/intl/locale/mozIOSPreferences.idl#92

Comment 7

[Magnus Melin [:mkmelin]]

This was fixed by bug 1370859. DateTimePickerPanel.jsm initPicker is now using the Services.locale.regionalPrefsLocales locale. That affects both date and time picker.

Comment 8

[Zibi Braniecki [:zbraniecki][:gandalf]]

This does not resolve pt 3 from my list in comment 6

Comment 9

[Magnus Melin [:mkmelin]]

Reopen, or new bug?

Comment 10

[Piotr Dobrogost]

(In reply to Zibi Braniecki [:gandalf][:zibi] from comment #6)

3. Once we have that, we could also use mozIOSPreferences API to identify the correct skeleton/pattern for the time picker. This pattern will take into account manual hourCycle set in the OS on Windows/Gnome/Ubuntu/MacOS/Android.

Why is KDE absent from this list?

Comment 11

[Piotr Dobrogost]

(In reply to Zibi Braniecki [:gandalf][:zibi] from comment #6)

Ok, so here are several things that may come into play:

1. We only use OS locale if the language portion of the locale matches the language portion of Firefox locale by default. That's documented in https://firefox-source-docs.mozilla.org/intl/locale.html#regional-preferences including a preference flag allowing users to override it manually.

The reasoning behind this given at the above link is flawed; the example given – “Today is 24 października” – is perfectly valid outcome of having English UI and Polish Date/Time format set. Firefox should always use locale of the OS Regional Preferences for displaying date and time regardless of the language of Firefox UI.

Just wanted to report that setting intl.regional_prefs.use_os_locales to true in Firefox 65.0.1 was enough to have Firefox respect my OS level regional settings and display time in <input type=time> in 24h format instead of 12h format.

From about:support;

Application Settings
Requested Locales ["en-US"]
Available Locales ["en-US"]
App Locales ["en-US","und"]
Regional Preferences ["pl-PL"] # ["en-US"] when intl.regional_prefs.use_os_locales == false
Default Locale "und"

Operating System
System Locales ["en-US"]
Regional Preferences ["pl-PL"]

Btw, this "und" locale seems to be a glitch…

My OS:
Operating System: Fedora 29
KDE Plasma Version: 5.14.5
KDE Frameworks Version: 5.55.0
Qt Version: 5.11.3
Kernel Version: 4.20.11-200.fc29.x86_64

Comment 12

[Zibi Braniecki [:zbraniecki][:gandalf]]

Reopen, or new bug?

No preference.

Why is KDE absent from this list?

Nobody provided KDE variants for https://searchfox.org/mozilla-central/source/intl/locale/gtk/OSPreferences_gtk.cpp - I'm open to reviewing that.

“Today is 24 października” – is perfectly valid outcome of having English UI and Polish Date/Time format set.

I disagree. It's a flawed juxtaposition of internationalization and localization. That effect gets magnified once you hit cases where it's hard to say which locale it is - there are a lot of abbreviation that can mean different things between two languages. I believe it's important for consistency and readability to stick to one localization of all internationalization.

Comment 13

[Magnus Melin [:mkmelin]]

Filed bug 1532923.