Closed Bug 1425218 Opened 2 years ago Closed 9 months ago

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

Categories

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

58 Branch
defect

Tracking

()

RESOLVED FIXED
mozilla67
Tracking Status
firefox-esr52 --- unaffected
firefox59 --- wontfix
firefox60 --- affected
firefox61 --- affected

People

(Reporter: adrian, Unassigned)

References

(Blocks 1 open bug)

Details

(Keywords: regression, Whiteboard: [fixed by bug 1370859])

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.
Component: Untriaged → Layout: Form Controls
Product: Firefox → Core
Priority: -- → P1
Status: UNCONFIRMED → NEW
Ever confirmed: true
Priority: P1 → P3
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.
Has Regression Range: --- → no
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

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?

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

Blocks: 1366188
Has Regression Range: no → yes
Flags: needinfo?(htsai)

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

Keywords: regression

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.

  1. 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.

  2. 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

Blocks: datetime
Flags: needinfo?(htsai)

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

Status: NEW → RESOLVED
Closed: 9 months ago
Resolution: --- → FIXED
Whiteboard: [fixed by bug 1370859]
Target Milestone: --- → mozilla67

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

Reopen, or new bug?

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

  1. 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?

(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

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.

QA Whiteboard: [qa-67b-p2]
You need to log in before you can comment on or make changes to this bug.