This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
input type=time has the 'max' and 'min' attributes to check the value range. And 'min' is mandated to be lesser than 'max'. For example, <input type="time" min="23:00:00" max="01:00:00"> would be considered non-conformant (see http://lists.w3.org/Archives/Public/public-html/2009Sep/0832.html). However, a time of 23:00:00 is not always later than 01:00:00. For night times, it makes perfect sense to allow times between 23h and 01h. I suggest to add something like "When min is greater than max, UAs will assume it to be a valid midnight-crossing interval", after the description of the min and max attributes.
Interesting feature request. I haven't added this at this time, because doing so is actually a pretty major change to the spec (it'd involve a refactoring of the way min="" and max="" are implemented, as well as some changes to validation, step="", and other aspects of the spec), but I've noted it as a feature for a future version. It definitely seems like something that would be reasonably added in the future, and I don't see why we couldn't add it later (it's a backwards-compatible change as far as I can tell).
Checked in as WHATWG revision r4034. Check-in comment: Note the idea of <input type=time> having an allowed range crossing midnight. http://html5.org/tools/web-apps-tracker?from=4033&to=4034
(In reply to comment #1) > I don't see why we couldn't add it later (it's a backwards-compatible > change as far as I can tell). Not sure. If the proposed change cannot be done at this time, perhaps adding something like "authors should note that setting min>max on a form field is not a valid way to alter form behaviour" could make sense, to avoid misuses that could break with future changes.
The spec currently says: "The max attribute's value (the maximum) must not be less than the min attribute's value (its minimum). If an element has a maximum that is less than its minimum, then so long as the element has a value, it will either be suffering from an underflow or suffering from an overflow." ...so validators will flag this as an error for now, which should help with your concern.
This bug predates the HTML Working Group Decision Policy. If you are satisfied with the resolution of this bug, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document: http://dev.w3.org/html5/decision-policy/decision-policy.html This bug is now being moved to VERIFIED. Please respond within two weeks. If this bug is not closed, reopened or escalated within two weeks, it may be marked as NoReply and will no longer be considered a pending comment.
I did not receive any email with the text in comment #5, so could not reply in time. This bug has the status of VERIFIED/LATER, hope this means that the "no longer a pending comment" policy does not apply. At least, not in the sense that it won't be considered in the future, as the current behaviour in the spec breaks POLA: for example, you can filter between 22 and 23 hours, but not the next hour between 23 and 0.
This bug was cloned to create HTML WG bug 19064.
Ok, I added this. It ended up being a little simpler to add than I expected, once I'd figured out how to limit the impact appropriately.
Checked in as WHATWG revision r8203. Check-in comment: Allow type=time to have min>max, so that times can span midnight. http://html5.org/tools/web-apps-tracker?from=8202&to=8203