This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 15114 - forms: new <input> type for YYYY / YYYY-MM / YYYY-MM-DD / YYYY-MM-DD hh:mm, at user's choice
Summary: forms: new <input> type for YYYY / YYYY-MM / YYYY-MM-DD / YYYY-MM-DD hh:mm, a...
Status: RESOLVED WONTFIX
Alias: None
Product: WHATWG
Classification: Unclassified
Component: HTML (show other bugs)
Version: unspecified
Hardware: Other All
: P3 enhancement
Target Milestone: Needs Impl Interest
Assignee: Ian 'Hixie' Hickson
QA Contact: contributor
URL: https://html.spec.whatwg.org/#date-st...
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-12-08 15:48 UTC by contributor
Modified: 2017-07-21 10:35 UTC (History)
8 users (show)

See Also:


Attachments

Description contributor 2011-12-08 15:48:31 UTC
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
Comment 1 Ian 'Hixie' Hickson 2011-12-09 23:03:04 UTC
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.
Comment 2 Ian 'Hixie' Hickson 2013-03-08 23:43:15 UTC
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?
Comment 3 Ian 'Hixie' Hickson 2013-04-12 23:21:29 UTC
bfrohs: Please see comment 2.
Comment 4 Brandon Frohs 2013-06-04 15:13:14 UTC
(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.
Comment 5 Ian 'Hixie' Hickson 2013-06-12 19:33:42 UTC
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.
Comment 6 Brandon Frohs 2013-06-12 20:23:03 UTC
(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)
Comment 7 Ian 'Hixie' Hickson 2013-10-02 21:00:24 UTC
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?
Comment 8 Brandon Frohs 2013-10-02 22:56:30 UTC
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).
Comment 9 Ian 'Hixie' Hickson 2013-10-03 19:02:46 UTC
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...
Comment 11 Anne 2017-07-21 10:35:06 UTC
Please file a new issue at https://github.com/whatwg/html/issues/new if there's still interest.