15114 2011-12-08 15:48:31 +0000 forms: new <input> type for YYYY / YYYY-MM / YYYY-MM-DD / YYYY-MM-DD hh:mm, at user's choice 2017-07-21 10:35:06 +0000 1 1 1 Unclassified WHATWG HTML unspecified Other All RESOLVED WONTFIX https://www.w3.org/Bugs/Public/show_bug.cgi?id=25742 https://html.spec.whatwg.org/#date-state-(type=date) P3 enhancement Needs Impl Interest 1 contributor ian annevk bfrohs ian mariahbanks2323 mike mounir robin slave.loren contributor oldest_to_newest 61242 0 contributor 2011-12-08 15:48:31 +0000 Specification: http://www.whatwg.org/specs/web-apps/current-work/multipage/states-of-the-type-attribute.html Multipage: http://www.whatwg.org/C#date-state Complete: http://www.whatwg.org/c#date-state Comment: A "date-optional-state" should be available, for when the specifity of the date is unknown. This would give the user the option of selecting a year, month, or day. Any additional requirements (e.g. required month) can be taken care of with [pattern]. Would be just like "date-state", but parameters on end would be optional (e.g. "YYYY[-MM[-DD]]"). Optionally, "0"s could be used, rather than omitting (e.g. "YYYY-00-00" or "YYYY-MM-00"). Example use case: Published Date for books. Publishers sometimes only list a month (esp. when published on different days across time zones), but more detail is preferred. Two inputs ("Month" and "Date") is not possible as it requires a script for validation ([required] for both locks form) and people try to fill out all form fields (duplicates is confusing). Using [pattern] as-is is not a solution as it does not present the user with a date picker. Posted from: 24.231.239.6 by bfrohs@gmail.com User agent: Mozilla/5.0 (Ubuntu; X11; Linux i686; rv:8.0) Gecko/20100101 Firefox/8.0 61348 1 ian 2011-12-09 23:03:04 +0000 I have marked this LATER so that we can look at this again once browsers have caught up with what we've specified so far. 84147 2 ian 2013-03-08 23:43:15 +0000 Can you elaborate on use cases, ideally with a reference to a page that does something like this so I can study how they expect the UI to work? 86110 3 ian 2013-04-12 23:21:29 +0000 bfrohs: Please see comment 2. 88620 4 bfrohs 2013-06-04 15:13:14 +0000 (In reply to comment #2) > Can you elaborate on use cases, ideally with a reference to a page that does > something like this so I can study how they expect the UI to work? Apologies for the delay, this got lost in my own personal abyss known as email. We went ahead and used a plain text input that expects "YYYY-MM-DD" or "YYYY-MM" format. All validation is done server-side, and if a date that doesn't match the required format is sent, PHP's `strtotime()` function is run on the provided text, and if it can read it as a valid date, the user is asked if that's what they meant to provided. For example, if "January 2013" was provided, `strtotime("January 2013")` would be called and the user would be asked if they meant "2013-01-01". It isn't ideal by any means, but it gets the job done. --- Had I had the time to work on a JavaScript date picker, I would have done something like "<- January -> | <- [2013] ->" with the dates listed below like "date" does, where "January" was a link that could be clicked just like any of the days, "<-" and "->" were buttons that would (in|de)crement the month, and 2013 could be an input box to change the year by a large amount easily. 89202 5 ian 2013-06-12 19:33:42 +0000 Right but what is the use case? That is, why do you need a field where some of the data isn't necessary? I'm just trying to get an idea of where to start researching this kind of thing to work out what the requirements are. 89207 6 bfrohs 2013-06-12 20:23:03 +0000 (In reply to comment #5) > Right but what is the use case? That is, why do you need a field where some > of the data isn't necessary? I'm just trying to get an idea of where to > start researching this kind of thing to work out what the requirements are. As mentioned in the original report: > Example use case: Published Date for books. Publishers sometimes only list a month (esp. when published on different days across time zones), but more detail is preferred. With that said, although we'd prefer to have the exact date that a book was published (e.g. YYYY-MM-DD), publishers/authors can't always provide this information. Sometimes they don't have the information readily available. Other times the book hasn't been published yet, and while the year or month is set in stone, the month or day hasn't been yet. Instead of forcing them to provide either an *exact date* or *nothing*, it's beneficial to be able to allow them to provide a partial date instead (e.g. YYYY-MM or YYYY). Using two different fields for this purpose would confuse users and be more difficult to achieve on the server's side of things. As a side note, it is rather common in the book industry for the day to be left out from the published date, even on sites such on amazon.com: http://www.amazon.com/dp/1585421464 - Includes day: > Publisher: Jeremy P. Tarcher/Putnam; 10 Anv edition (March 4, 2002) http://www.amazon.com/dp/0961392142 - Does not include day: > Publisher: Graphics Pr; 2nd edition (May 2001) 94204 7 ian 2013-10-02 21:00:24 +0000 Hm, interesting. So this is basically a form control that could be anything from type=number (just a year) all the way to type=datetime (a year, month, day, hour, minute, second, time zone offset), and you don't necessarily know which... I wonder how common this is. If it's pretty rare, it might be best to let authors make their own widgets with Web Components for it. If it's common, we should support it. Book publication dates are one case (year-month or year-month-day, it seems?). Are there others? 94213 8 bfrohs 2013-10-02 22:56:30 +0000 Yes, year-month or year-month-day, although I'm sure year by itself could be necessary at times for some. This format also applies to movie/show release dates: http://www.imdb.com/title/tt0111495/releaseinfo (Note USA release date is missing the day). Also, a "year-month-day" or "year-month-day hour:minute" is another common use, specifically for scheduling events/reminders in the future: Google Calendar has an "All Day" checkbox when creating a new event that, when checked, hides the second input box for the time for the start/end. Facebook Events do something similar, but instead of a checkbox, they simply allow you to leave the time input blank. Their date input has a clickable calendar and their time input is a text field that drops down a list of times in 5 minute increments (after you begin typing a time). In the "Work and Education" of Facebook profiles, you have the ability to enter year, year-month, or year-month-day. Initially, it's presented as a year select, then you can click "Add month" to choose a month from a second select, then you can click "Add day" to choose a day from a third select. So, like you suggested, an element that could handle every variation from only the year to the full date would be incredibly useful, so long as it had a minimum amount required (e.g. year-month) and a maximum amount allowed (e.g. year-month-day). 94258 9 ian 2013-10-03 19:02:46 +0000 Hm, interesting cases, thanks. A lot of these cases have explicit UI; it might make sense to just let authors use the existing controls with buttons to switch between them. But I agree that would be somewhat ugly if browsers are willing to implement a single control instead... 124543 10 mariahbanks2323 2016-01-07 21:40:22 +0000 128742 11 annevk 2017-07-21 10:35:06 +0000 Please file a new issue at https://github.com/whatwg/html/issues/new if there's still interest.