This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Specification: http://www.whatwg.org/specs/web-apps/current-work/multipage/common-microsyntaxes.html Multipage: http://www.whatwg.org/C#durations Complete: http://www.whatwg.org/c#durations Referrer: http://www.whatwg.org/specs/web-apps/current-work/multipage/ Comment: Durations in precise moments of time. Posted from: 84.220.43.211 by master.skywalker.88@gmail.com User agent: Mozilla/5.0 (Windows NT 6.3; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/33.0.1750.117 Safari/537.36
Durations can be expressed in other forms according to the ISO 8601 specification. I.e. durations can be in the form of START/END, START/DURATION, DURATION/END (where START and END are valid dates and DURATION is a valid duration string in the ISO specification). Why aren't they present in this spec?
Not only are those kinds of durations not supported, but month-based durations are also not supported. Only second-based durations. So far, I don't think anyone has implemented the table sorting algorithm, which is the only thing that really uses this in browsers. Adding more duration types would just make that even more complicated, delaying implementations even further. So unless there's a really compelling need, I'd rather not add anything like this yet. Note that for private use, you can use the existing features already. In particular, START/END, START/DURATION, and DURATION/END are all redundant with just giving two <time> elements with the relevant parts.
Almost redundant. Actually authors are forced to use other features, like custom dataset attributes, in order to mark times as start or end. Which is anyway possible but it lacks standardisation. I don't know the relationship between duration and the table sorting algorithm, but perhaps HTML could implement a subset of the ISO8601 duration models, namely the start/end model (or, which would be worse perhaps) the start/duration (so that starting times can still define a chronological order) and discarding the duration/end. I agree on the lacking support of month-based duration, of course. <time> in webpages is useful for marking dates, time tables, events and so on, and I think there are really few cases (if any) when month-based durations are clear on their own (day-based durations work better). But in events the most common indication of periods of time are from the start to the end, more than simple durations.
I thought better about that and actually semantic markup and Schema.org can mark start, end and duration of events (itemprop="startDate", itemprop="endDate", itemprop="duration"), so actually the need is not compelling. Sorry.