Problem / Motivation

Make the new HTML <input type="date" .../> element available as an FAPI element in core.

References

W3C: http://www.w3.org/TR/html5/states-of-the-type-attribute.html#date-state

CommentFileSizeAuthor
#2 html5-date-element-1496632.patch5.57 KBLSU_JBob

Comments

LSU_JBob’s picture

LSU_JBob commented
Assigned: Unassigned » LSU_JBob
LSU_JBob’s picture

LSU_JBob commented
Status: Active » Needs review
StatusFileSize
new html5-date-element-1496632.patch5.57 KB

using the name "form_date" to avoid conflicts for now.

hansyg’s picture

hansyg commented
Issue tags: +html5

Status: Needs review » Needs work

The last submitted patch, html5-date-element-1496632.patch, failed testing.

Niklas Fiekas’s picture

Niklas Fiekas commented

Thank you, @LSU_JBob.

Important question on how to proceed: How to handle the value internally?

  • As a timestamp, e.g. 138849.
  • As a string, which is how the value gets passed from the browser, e.g. 1999-03-04.
    Disadvantage: Hard to process.
  • As an array, e.g. array('year' => 2005, 'month' => 5, 'day' => 23). This is how the current date element does it.

TODO: Discuss this with KarenS or open an issue on http://drupal.org/project/issues/1512146?categories=All.

LSU_JBob’s picture

LSU_JBob commented

No timestamp, makes the most sense but I've always had problems with it when I try to go way way back in time. Like 1800's and stuff...

I like the array, keeps things format agnostic for when things get dicey with dates, like when displaying the date according to locale.

LSU_JBob’s picture

LSU_JBob commented
Assigned: LSU_JBob » Unassigned

Unassigning from myself in case that's stopping anyone from throwing a patch up :) I'll still be looking at this though.

cosmicdreams’s picture

cosmicdreams commented
Assigned: Unassigned » cosmicdreams

Assigning to me because I'm excited to get this one done (even though it's not supported widely in browsers yet)

dave reid’s picture

dave reid
he/him
Primary language English
Location Nebraska USA
commented
Assigned: cosmicdreams » Unassigned

We should go exactly with what the format of HTML5 date says, and use a string in the format of 'Y-m-d' (e.g. 2012-09-11).

cosmicdreams’s picture

cosmicdreams commented
Assigned: Unassigned » cosmicdreams

agreed

cosmicdreams’s picture

cosmicdreams commented

I just tested the latest Opera (12.01) and found that it supports the following:

<date>
<time>
<month> 
<week> 
<datetime> 
<datetime-local>
karens’s picture

karens commented

Desktop browser support is really pitiful for this, but mobile support is good. Using the string seems to be what most people are doing, it is human-readable, and it corresponds to the way microformats and RDF are handled.

I actually hope to introduce a patch for a more complete set of date elements in core, but this is the place to start I guess.

Anonymous’s picture

Anonymous (not verified) commented

An ISO8601 string would probably be best for storing internally.

The HTML5 spec doesn't provide a single standard, it provides many different options, assuming that the consumer will know which is being used based on other semantics, like microdata.

#1347648: Change date_iso8601 to format the 9 HTML datetimes is related.

karens’s picture

karens commented
Status: Needs work » Closed (duplicate)

I think this is unneeded now, #501428: Date and time field type in core includes all the HTML5 date elements. If anyone thinks that patch needs changes you could post on that issue.