[whatwg] Please consider adding a couple more datetime <input> types - type="year" and type="month-day"

[Christoph Päper]

Ryosuke Niwa:
> 
> All popular calendar systems should be supported.

Browser widgets for the datetime types may support more than proleptic Gregorian, but the spec shouldn’t. ISO 8601 or a subset thereof should be the interchange format; clients and servers, before and after, may handle it however they deem useful.

It makes sense to be able to specify other calendaric elements than just a specific day (YYYY-MM-DD or YYYY-DDD – these differ only in leap years). ISO 8601 offers several other specific items (month: YYYY-MM, week: YYYY-wWW, day: YYYY-wWW-D, year: YYYY) and several unspecific items (-DDD, -MM-DD, --DD, -wWW, -wWW-D, --D). If I remember correctly splitting the century component from the year was only in previous versions of ISO 8601. (Almost the same goes for time of the day, of course.)

The thing is those items hardly ever exactly match their equivalent types in other calendars: the months are very proprietary (even hardly compatible with Julian), the ISO week (Mon–Sun, no splits) is not the same as the Christian/Hebrew (Sun–Sat, no splits), US (Sun–Sat, splits), TV/Muslim (Sat–Fri, no splits) week or the work-week (Mon–Fri), and sometimes even the day is not the same because it doesn’t run from 00:00Z through 24:00Z. The standard doesn’t define semesters, trimesters or quarters (e.g. 3 months or 13 weeks) of any kind and neither does it say anything about seasons, zodiacs, phases of the moon or other days not bound to a single month-day or week-day. It features two types of year with different lengths (365+1 days and 52+1 weeks) sharing a common numeric designation.

The 12-hour clock does not pose any problems (if supported in browser widgets), because it maps exactly to the 24-hour clock – unless you want to be able to select ‘AM’ or ‘PM’ without giving an exact time, but why stop there with dichotomy when ‘night’, ‘daylight', ‘afternoon’, ‘evening’, ‘dawn’ etc. may be equally viable selections?

Tantek and others provided use cases already for several of the types available in ISO 8601:
YYYY:       year of birth without revealing birthday
-MM-DD:     birthday without revealing age
-MM:        should this be ‘month’?
YYYY-MM:    credit card expiration, calendar page selection
--D:        day to show in a weekly recurring pattern, e.g. TV or school schedule
--DD:       day to show in a monthly recurring pattern, seldom
-DDD:       day to show in a yeary recurring pattern, rare
-wWW:       should this be ‘week’?
-wWW-D:     repeating week dates, perhaps including some holidays
YYYY-wWW:   accounting, work schedule, may be mappable to TV weeks etc.
YYYY-wWW-D: can usually be substituted by YYYY-MM-DD or YYYY-DDD
YYYY-DDD:   can usually be substituted by YYYY-MM-DD
±YYYY…:     history
±Y*YYYY:    astronomy, geology, geography, palæontology etc.

To support items other than ISO year, month, week and day, it might be useful to somehow support any arbitrary period by way of time intervals (including the P syntax) in ISO 8601. The current TV week was for example 2010-W31-6T03:00/P1W or 2010-W31-6/W32-5.

User Interface

Someone mentioned Nielsen’s research results that simple textual input is preferable for dates. That is true (and mostly irrelvant here), but only when the date is known exactly, as with your own birthday, but may already fail when you have to enter tomorrow or next Thursday (and assume that “tomorrow” and “next Thu” are not valid inputs, although they should be), since you may know today’s weekday and month but not the numeric position inside the month nor the week number.