<input type="time"> : Time vs. duration

[d-damien]

When you want to enter a duration less than a day, it will generally be better understood in HH:mm:ss format by the user. Using <input type="time" /> works well in a language that's on a 24H basis, but when trying it with a browser in english :

• They have to enter AM/PM, which doesn't make sense in this context.
• They cannot enter durations over 12:59.
• Other use case : military time uses 24H cycles.

An easy workaround would be to have a way to override user's default to force 24H cycle. I think otherwise behavior is just the same as time. I'm not sure which of type="duration" or cycle="24h" would be best here.

[annevk]

So in particular, you want to convey a particular UI locale that makes sense for your site? In theory I think you can express this in a language tag and in theory browsers should honor that, but in practice none of it is that perfected.

[annevk]

cc @whatwg/forms

[d-damien]

I don't know ; semantically that's not the same thing. One would have to pick a country that uses 24h clock ; that would work but feels a bit hack-ish. Also, albeit unlikely, a country could choose to go back to 12h clock.

[d-damien]

It must apply only to a given input, not the whole site. Is it allowed to use language attribute on a single input tag ?

I believe the concept of duration is quite generic.

[annevk]

Maybe I'm wrong. I thought you could do something akin en-US-24hclock (not that exact syntax). And yeah, the lang attribute applies to all elements.

[d-damien]

I couldn't find that anywhere I looked.

type="duration" might not the best option as other durations fields (more than a day) could appear in the future (as specified by ISO 8601, for example). clock="24h" maybe.

[tabatkins]

Yeah, @d-damien is looking for a "duration input", and just noting that, at least in some locales, type=time acts as a decent approximation of that for durations <1 day.

But I don't think we should be trying to hack things in this way, or adding new features to accommodate this hacky usage. We should either accept durations as a first-class form of input, or reject the proposal entirely.

[d-damien]

I think it would be interesting to have an even more generalist field, maybe something that has an ISO 8601 duration as value, but as no interest is shown I'll close it.

[muan]

I'd love to see this re-open if possible. There are quite some use cases where this can be useful: setting a duration for a recurring reminder, a meeting, a generic timer, or media trimming start and end, off the top of my head.

And I agree, type=duration would be much preferable to hacking away with type=time.

Currently it seems like the "easiest" solution would be to have multiple number fields each labelled with days/hours/minutes/seconds each set with min/max and using JS to do the math between these fields, which would also then need to be convey to screen readers, like when stepping up one minute changes it from 00:59:30 to 01:00:30.

[muan]

I've built a custom element for this for now/as a reference: https://github.com/muan/input-duration-element/

[domenic]

Adding agenda+ to try to probe implementers on where this falls on the effort spectrum, and/or what it would take for them to consider it.

[hsivonen]

What's the level of evidence of a duration input being common enough a need? For example, is it common for JS UI frameworks to provide their own duration input?

[bkardell]

We talked about this in the triage meeting and a question was asked about whether this came up in OpenUI or something - I said that I thought I recalled a similar thing but couldn't find it at the time. My recollection was poor, it was not an input type, but rather something about measures https://github.com/openui/open-ui/issues/499 - just recording that here in case it comes up again as a question

[annevk]

Questions that came up (that echo those from @hsivonen above):

1. Is there precedent for this in OS software?
2. Is there framework/library support?
3. Is this an oft-requested feature? E.g., lots of questions on Stack Overflow.

[domenic]

Note that we've taken this off the agenda for the meeting, as we believe we cannot make much further progress without answer to @annevk's questions. If the web developer community wants to drive this, assembling such answers would be a good next step. The more detail the better. For example, if you can do a comparative survey of how this control appears in different UI frameworks (including native OS UI frameworks, both desktop and mobile), that would significantly help both motivate the feature and determine the implementation difficulty. Similarly, as part of such a survey, it would be good to give a detailed accounting of what sort of UI and capabilities is expected here, e.g. durations >24 hours or no, two-<select>s or some sort of clock-looking thing or two <input type=range>s or...?

[muan]

Since I was the one advocating this to be reopened, I now feel differently, so I'd let editors decide if it should remain open.

I still think this can be useful, but probably as useful as the longtail of UI components that can be useful for web developers right now. The custom element resolved my need for this, and I think that's fine enough, and is exactly what custom element is for.

That's to say I think it's fine close this until someone wants to drive this forward.

[Crissov]

Durations or periods are tricky. ISO 8601 specifies formats (PnYnMnDTnHnMnS, PnW, PT) for them in the context of time intervals, which have a start or end or both. WHATWG HTML already supports a subset of that. They can use any of a number of temporal units, which are not related to each other by a factor of a power of ten. They may even differ by context, e.g. in Jira estimations and work logs 1w 1d is equivalent to 48 hours by default, not 192 hours.

However, this is also exactly why it would make sense to have this handled by a standardized element. If the value will be stored as a single number, it’s ultimately a matter of numeric presentation and user input parsing. Entering something like 1h 15m or 1:15 or 75" which is transmitted as 4500 seconds is really no different from entering 6ft 2in or 6'2" treated as 1.8796 meters internally. Geographic coordinates, for instance, have similar issues.

The common pattern is: a number represented by one or more numbers with inherent factors (vulgo: a unit) which may be indicated by symbols or by grouping.

I do not have a perfect solution for this. I think it should be handled by a new attribute (or two) for the <input> element, not by a new value for the type attribute. This should be applicable only to certain values thereof, though, notably number.

Perhaps we first need a unit or a dimension attribute, which informs the browser how the numeric value is interpreted by the backend. This could already afford special GUI widgets, possibly taking system locale and document language into account. #4454 #5055 Another attribute could then assist the browser in further limiting the choices available. The capabilities of pattern and step are not sufficient for this. #1086

PS: Also see https://github.com/openui/open-ui/issues/499

[StephanLuis]

Time = Duration the ISO 8601 time section on wikipedia standardises formats for hours to thousandths of a second. Those are the universal (global) representations of time and seems fine for a HTML control.

The only other consideration is the SI unit of time is S (seconds). So those two can be bundled where user input/values are parsed colons from right to left starting with seconds and a decimal for seconds. Values for seconds and minutes are updated and displayed base 60.

Scientifically -- time -- is fundamental, the social (ex calendars) aspects should be programmed as extensions or separate HTML controls ... but somehow development has happened the other way. Now programmers are tinkering with a complex w3c standard to get the basic unit to work. That is 'anti-scientific'.

Like @muan my version of a input-duration on NPM recently ... by this stage though most projects that need one have programmed their own or have just accepted that they will program one if they need to. But it's a wasteful expense.

For a laugh have a look at how the google countdown timer is implemented. It's over 20 lines of html produced by I have no idea how much JS. Ideally there should be one control ... programmable (if needed) by 'scratch.mit'.

[aphillips]

(reviewing this thread for I18N WG; adding a couple of quick observations) CLDR and ICU provide a number of unit conversion mechanisms as well as some data related to time values in particular. There is data and there are mechanisms available to user-agents for working with durations and periods.

I also don't see hourCycle mentioned anywhere directly (it's implied by the discussion of 24-hour vs. am/pm).

[StephanLuis]

@aphillips Great to see this is 'on the radar'... thanks for having a look.

You are correct there are probably sufficient internationalisation mechanisms for time. There is a question that I18N WG could address relating to a 'base unit' of time ... are there any hurdles to international use of ISO 8601 for a time unit in HTML like hh:mm:ss.sss ?

My previous post above explains the need to update to the HTML standard ... unless there is some place (in the world) where computer scientists would not understand the time units hours, minutes, seconds. The I18N WG might authoritatively answer that question so to begin the process of addressing this void in the 'spec' and huge amount of waste in reverse engineering code for a base unit of time in HTML.

[StephanLuis]

@aphillips How did that WG meeting go? I'm not too familiar with the W3C working group meetings, but I saw on the I18N website that the meetings are open to new members. Do you think that it would be worthwhile to pursue this 'issue' that I have to join a working group to address this need that I see in the HTML spec? From your experience which group would be best positioned to make progress ? Thanks.

[aphillips]

are there any hurdles to international use of ISO 8601 for a time unit in HTML like hh:mm:ss.sss ?

ISO 8601 provides serialization forms to support most time-related applications and, when it catches up with Temporal/SEDATE, should close existing gaps related to time zones.

Durations are different from time values. One problem is deciding which "clock tick unit" to use for them: seconds, milliseconds, or nanoseconds? Or does one want to have variable units (2 days, 9 hours, 56 seconds)? @StephanLuis, you're suggesting using millisecond precision, which is consistent with most (but not all) timekeeping systems. It's a reasonable compromise, but the HTML folks need to decide what to do here. I18N APIs exist in all of the major browsers to implement display of such increments, so that's not a barrier, AFAICT. I18N's interest in this thread is that sometimes proposals are created that are tied to specific locale input/presentation of time. At the moment, I don't see anything where we would want to intervene.

---

@StephanLuis If you want to affect what HTML does, WHATWG is the place to be. 😄

W3C I18N works to support internationalization of HTML. We provide advice and feedback and serve as a liaison to the I18N community. We don't make the decisions, but we help WHATWG folks to do so (including pushing back where needed).

Employees of W3C Member organizations can join the I18N WG; others may apply for Invited Expert status (we have lots of these: I am one of these). If you are not a member and wish to discuss something, send the chair (that's me) an email. Please don't reply about W3C participation here 😉

[StephanLuis]

@aphillips Thanks! Based on what you know about WHATWG what is the best way to get involved? I have already spent a few hours chatting about this with the members online at the time, but the attitude was that I should develop a javascript shim and depending on the popularity of that ... then changes could be considered. To me that seems too slow a process at this stage of the spec development. What's your take?

[StephanLuis]

@aphillips btw my shim is input-duration on NPM. Not popular yet will aim to publish on webcomponents.org on the next round of updates.