Ah got it, thanks Simon! Bit confusing; on that page they say:
Browsers that don’t support time inputs gracefully degrade to a text input, but this creates problems both in terms of consistency of user interface (the presented control will be different), and data handling.
The second problem is the more serious; as mentioned previously, time inputs’ values are always normalized to the format hh:mm or hh:mm:ss. With a text input, on the other hand, by default the browser has no idea of what format the time should be in, and there multiple ways in which people write times…
So I guess it converts to hh:mm:ss but some browsers indicate it as hh:mm + am/pm (e.g. in Chrome those last two dashes are AM/PM, not seconds). But they do also list some possible workarounds:
One way around this is to put a pattern attribute on your time input. Even though the time input doesn’t use it, the text input fallback will.
The best way to deal with times in forms in a cross-browser way, for the time being, is to get the user to enter the hours and minutes (and seconds if required) in separate controls (
Personally I’m used to seeing a dropdown selector for time; something like in Google Maps looking up directions for a specific time, it’s a dropdown w/ half hour increments but you can also manually enter as text. the jQuery Timepicker thing seems similar to that, maybe a good way to go.
Just a guess but I would think w/ Discourse’s time-picker use cases specifically it’s probably pretty rare to need to schedule stuff for super granular times and a dropdown w/ something like one-hour increments could be a fine default.