Allow HTML web apps to force 24 hour time format in <input type=time>

[skissane]

https://html.spec.whatwg.org/multipage/forms.html#input-author-notes

The time, date, or number given by the page in the wire format is then translated to the user's preferred presentation (based on user preferences or on the locale of the page itself), before being displayed to the user

For some web applications you want to always use 24 hour time format, even if the user has set a 12 hour time format preference. Some reasons why you might want to do this:

• 24 hour time format is standard in the application domain. Examples:
  • here in Australia, the majority of the people have their devices set to 12 hour time, but transport timetables (train, bus, etc) very often use 24 hour time. (The various operators are inconsistent – trains in Sydney use 24 hour time but trains in Melbourne use 12 hour time – but still a given transport operator will have a standard and stick to it.)
  • US mainly uses 12 hour time, but certain professional contexts prefer 24 hour: the military, medicine, science
• The time is specified in UTC and am/pm don't make much sense for UTC timestamps.

This is a real requirement that people have. Right now, if you want to force 24 hour time, you have to use a custom time control rather than pure HTML. It would be better if there was some kind of attribute, e.g. timeformat="24h", that could be used to force 24 hour regardless of user settings.

Here are some StackOverflow questions asking for this:

• https://stackoverflow.com/questions/32609407/html-input-time-in-24-format
• https://stackoverflow.com/questions/31829783/in-different-browsers-input-time-field-shows-in-different-formats
• https://stackoverflow.com/questions/13523060/how-to-change-the-time-format-12-24-hours-of-an-input

Tentative proposal

Add a new attribute to <input> element, timeformat. Allowed values are "24h" or "auto". When "auto" (default), it decides whether to use 12h or 24h time format based on user preferences (locale, regional settings, etc), which is the current behaviour. When "24h", always use 24 hour regardless of user preferences.

Even when timeformat="24h", the display of the time still depends on the user's locale – the same time might be displayed as 15:30, 15.30, 15h30, 1530, etc, depending on the user's locale settings. timeformat="24h" just forces the selection of the 24 hour time format for that locale even if the locale (or the user) prefers its 12 hour time format.

Should HTML support forcing 12 hour format as well?

One question is whether to support timeformat="12h". I think that may be problematic in that in some countries 12 hour time format is largely unused, and users may be unfamiliar with it. A web application author forcing 12 hour time, even when the user is in a locale where 24 hour time is standard, may cause an unpleasant user experience. It might particularly happen where a developer is in a country where 12 hour time is the norm decides on timeformat="12h" to the detriment of users in other countries who are unfamiliar with it. By contrast, even in those countries where 12 hour time is the norm, 24 hour time is still used in some application domains, and so users in 12 hour time countries often still have some familiarity with and understanding of 24 hour time even if it isn't their preference. You could also say that it is more justifiable to support overriding the user's preference towards the international standard (24h) than away from it. Given all of this, I'd suggest explicitly not supporting timeformat="12h", in spite of the symmetry argument in favour of doing so. (However, I don't feel strongly about it.)

Of course, if someone really wants to force 12 hour format, they can always do that with a custom time control/widget, and the HTML spec can't stop them. But the spec should encourage people to do the right thing, by making doing the right thing easier and the wrong thing harder. Forcing 12 hour format is much more likely to be the wrong thing (user-unfriendly) than forcing 24 hour format is going to be. There are application domains where 24 hour is the norm even in countries which prefer 12 hour format. I'm not aware of any application domains where the reverse applies.

[annevk]

Thanks for the write-up and links to Stack Overflow! (https://whatwg.org/faq#adding-new-features and https://whatwg.org/working-mode#changes might be of interest.)

#4523 is related and it might be worth it to deduplicate.

@whatwg/forms thoughts on this?

[Stalfur]

The inability to force 24h format means this input can't be used in a lot of places where browsers erroneously think they should be using AM/PM.

[dhaviaron]

I think we should have the option to enforce the 12h system as well, I don't think that “Forcing 12-hour format is much more likely to be the wrong thing” Every project has its own interests, requirements, and individual application, we shouldn't be making developers work even more difficult just by pretending we know what's better to everyone

[aphillips]

Note that there are not just two systems for "hour cycle": there are actually 4 systems (0-11, 1-12, 0-23, and 1-24). Three of the four are defaults for some locale. I would recommend that you follow Intl.Locale in JavaScript to ensure interoperability with Intl.DateTimeFormat and CLDR. Note that the tokens (values) for hour cycle are typically h12, h24, etc. rather than 24h as proposed.

Here's a link to hourCycle in MDN for reference. Note that I18N WG just started revising working with timezones this past week, which you can track here.

[Stalfur]

Just want to reiterate that depending on the smart behavior of reading locale isn't always the right behavior. Logging in from a foreign PC/smartdevice, or where English is base OS language for a foreign language with a locale that the English one overrides in browser (as it is for me) etc would all make the "smart" guessing make the wrong decision.

As for the type of fomat the more the merrier, it just needs to be an option for developers - allowing the default behavior to stay the same.

[johanneswilm]

The authomatic localization that cannot be customized by the web author also happens to date and numbers [1].

I'm working on a project where this is problematic. The users of this specific internal web system expect to be able to enter numbers and dates in the Danish format, but they have all set the default language/locale of their computers to US English. Many official websites in Denmark use alternative input fields to get around the restriction that these formats cannot be changed by the web author [2]. My users were partially unaware and partially did they not care about the option to change the language/locale of their OS to Danish, probably because Danish language support overall is not as good as English. Users are using both Windows and Mac OS and are non-technical users working in a medical environment.

[1] https://html.spec.whatwg.org/multipage/forms.html#input-author-notes

The time, date, or number given by the page in the wire format is then translated to the user's preferred presentation (based on user preferences or on the locale of the page itself), before being displayed to the user

[2] See for example the fields "Fra" and "Til" at the top, search interface for Danish national archive https://www.sa.dk/find/

[skissane]

Note that there are not just two systems for "hour cycle": there are actually 4 systems (0-11, 1-12, 0-23, and 1-24). Three of the four are defaults for some locale. I would recommend that you follow Intl.Locale in JavaScript to ensure interoperability with Intl.DateTimeFormat and CLDR. Note that the tokens (values) for hour cycle are typically h12, h24, etc. rather than 24h as proposed.

@aphillips I am not sure if this would be the right approach. You are right that from one perspective there are four different systems (12 vs 24 hour on one dimension, 0-based vs 1-based on the other). However, from another viewpoint, there are only really two systems (12 vs 24), combined with two different ways of writing each of them (0-based vs 1-based). The application may have domain-specific reasons to insist on one of those systems regardless of locale, but might be happy to leave the 0-based vs 1-based question up to the locale. Just specifying 12 vs 24 would allow that, forcing specification of h11 vs h12 vs h23 vs h24 would not

The most flexible solution would be something like this (syntax is purely indicative):

Token	Meaning
h11	Zero-based 12 hour time (0-11)
h12	One-based 12 hour time (1-12)
h23	Zero-based 24 hour time (0-23)
h24	One-based 24 hour time (1-24)
12	Whichever 12 hour format is preferred by current locale (either h11 or h12)
24	Whichever 24 hour format is preferred by current locale (either h23 or h24)

That way, if an app wants to force the zero-based vs one-based aspect, it can. But if it just wants to force the 12-vs-24 yet leave zero-based vs one-based up to the locale, it can do that too.

This would be the maximally flexible solution, although maybe it is complexity overkill???

[Raiondesu]

Wouldn't it make the most sense to use the same format as in the Intl.DateTimeFormat options for consistency?