This article is a stub. You can help the whatwg.org wiki by expanding it.
Research, data, use cases, issues, and enhancements related to the HTML5
new date time inputs
The current new date time inputs cover a number of interesting and broad use-cases of various levels of granularity for absolute date and time input types:
* month (specific year, month) * week (specific year, week (implied month(s))) * date (specific year, month, day) * datetime (specific year, month, day, time) * datetime-local (specific year, month, day, time, timezone)
As well as one floating time input:
* time (specific time, but no specific day, month or year)
This set is missing a few date time inputs that would make sense in such a more complete collection of granularity and floating (non-absolute) date time inputs:
* year NEW: (specific year) * month (specific year, month) * week (specific year, week (implied month(s))) * date (specific year, month, day) * datetime (specific year, month, day, time) * datetime-local (specific year, month, day, time, timezone)
* month-day NEW: (specific month, day) * time (specific time, but no specific day, month or year)
new datetime input use-cases
- year - see the time element year only use cases
- pull-down for Wikipedia which lets you choose the year or period
- a charting application which looks at trends in history
- month-day - see time element month day only use cases
- inputting a birthday without birth year
- entering custom annual holidays
Additional use-cases for each of these new inputs are documented in proposals for allowing the respective levels of granularity/floating date/time support in the time element.
new datetime input discussion
Opinions / discussion:
- +1 Tantek - any implementer that is going to the trouble of properly implementing the existing 6 new date time inputs will find it fairly easy to implement two additional variants, and this more complete model of date and time inputs will be easier to remember for web authors (fewer exceptions to remember).
- +1 Andy Mabbett - Per the above, and examples/ use cases on time element.
new datetime input FAQ
how is a year different than a four digit number
Question: How is a "year" input any different from a four-digit input type="number" field?
Answer: It's not "just" an alias. It is very similar, however different in that:
- It has the *semantic* of being a year, which is a special type of number (potentially more than four digits if you subscribe to "Long Now" methodology.
- This semantic gives browsers the opportunity to present a "year" picker control that is styled in appearance consistently with other datetime inputs (rather than just a number input)
- This semantic gives robots the opportunity to understand that a form takes time based information rather than just a number (if for example robots perform time based form submissions/searches on our behalf at some point)
- Years can also be more of fewer than four digits. Julius Caesar was born in 100
BC, for instance, while Manius Acilius Glabrio was consul in 91 AD.
how does year provide additional validation
Question: What sort of additional validation you would need in a year field that you couldn't accomplish with "number" with a size of 4?
Answer: See above for the additional semantics that a year provides above and beyond a 4 digit number (and that years are not necessarily 4 digits). One source of additional validation could come from only permitting years since the transition to the Gregorian calendar, unless another calendar scale is specified (see related Time element proposal).
how would a year input appear in visual UAs
Question: How would such an input would appear in visual UAs?
Answer: The specific visual appearance is up to UA designers. Currently there is quite a bit of variance/experimentation of what datetime inputs look like from browser to browser (e.g. Safari, Opera), or even across different versions (Opera 10.55 vs 10.6) or even across devices (Mobile Safari vs. Safari).
- time - the time element, related proposals.