Closed Bug 1749036 Opened 4 years ago Closed 4 years ago

Browser not respect 12- or 24-hour time format by system locale on input type time

Categories

(Core :: Layout: Form Controls, defect)

Firefox 97
defect

Tracking

()

RESOLVED DUPLICATE of bug 1705310

People

(Reporter: mandel99, Unassigned)

Details

Attachments

(1 file)

Attached image time.png

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/96.0.4664.110 Safari/537.36

Steps to reproduce:

I use on my system 24-hour time format but browser use 12-hour format
(based on browser language) on <input type="time">

i read this : "firefox" also uses a 12- or 24-hour format for inputting times, based on system locale.
on:
https://developer.mozilla.org/en-US/docs/Web/HTML/Element/input/time
but this is not true.

Actual results:

Browser display 12-hour time format on <input type="time"> when system is 24-hour

Expected results:

Browser should display 24-hour time format on <input type="time"> when system is 24-hour (not based on browsel language)

The Bugbug bot thinks this bug should belong to the 'Core::Layout: Form Controls' component, and is moving the bug to that component. Please revert this change in case you think the bot is wrong.

Component: Untriaged → Layout: Form Controls
Product: Firefox → Core

I see the same issue on macOS: the format displayed by <input type="time"> depends on the region selected in System Preferences, but does not respect any change to the 12/24-hr option there.

Arguably, this is doing just what https://developer.mozilla.org/en-US/docs/Web/HTML/Element/input/time describes: it's using a format "based on system locale". But it is not accounting for modifications to the system locale's settings that the user may have requested, which seems like a shortcoming.

Severity: -- → S3

See bug 1705310. Or is this different somehow?

Flags: needinfo?(jfkthame)

Yeah, I think bug 1705310 covers it. In particular, bug 1705310 comment 9 suggests that in principle we could consider handling the hour-cycle here, but currently it's not supported.

Status: UNCONFIRMED → RESOLVED
Closed: 4 years ago
Flags: needinfo?(jfkthame)
Resolution: --- → DUPLICATE

So this is a wontfix? In our company we use Firefox as a corporate browser, but we cannot change the browser language as well as the system settings. So it's all in en-us. The only thing that can be changed in the system is the time format. so the system is en-us, the browser is en-us and the time setting is 24-hour, in our region the 12-hour format is not used and many employees do not understand it (AM-PM). Unfortunately, many internal systems use <input type ="time"> but all display a 12-hour format.

Or if we have the option to set a time interval for generating reports for example 5 hours back from now, then it looks like "generate my report from 5 AM(PM) to now"...

Is there any other way to force a 24-hour time format?

So... we could add an override pref here, or so, but that doesn't seem great because it'd just fix the <input> controls. Maybe it's good enough for your use case?

I think ideally we should be able to add a check somewhere around DateTimeFormat::ResolveComponents or so? There's also this code which looks somewhat related, and these preferences, but I'm already out of my depth on how these interact and whether they could be made to do what you want.

Jonathan / Dan, thoughts?

Flags: needinfo?(jfkthame)
Flags: needinfo?(dminor)

A great option would be to set the hour format according to the "lang" attribute something like <input type="time" lang="cs"> to force user defined region.

We do that for <input type=number> so that's probably ok.

From https://bugzilla.mozilla.org/show_bug.cgi?id=1705310#c9, I think it's a deliberate decision to not expose these prefs to <input> controls. The idea in comment 7 seems good to me.

Flags: needinfo?(dminor)
Flags: needinfo?(jfkthame)
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: