Specifying the value output of of an HTML5 input type = date?

Question

I'd like to add native date pickers to my application, which currently uses a legacy, home-rolled system. Date input support isn't widespread, yet, but if I could present both implementations based on compatibility, that would be ideal.

Is there any way to specify the output of the value given by an HTML datepicker? The default for opera is yyyy-mm-dd, and I very explicitly need dd-MMM-yyyy.

Is there any way to control this output, currently?

Solution 1

The HTML5 date input field is specific about the format it uses: RFC 3339 full-date

Is it possible to change the legacy date picker to use yyyy-mm-dd format (and update the server side that reads that)?

I assume not, so then you can add some Javascript glue code that listens for a change event on the HTML5 input and updates a hidden date value field to match the format of the legacy date picker (converts yyyy-mm-dd to dd-MMM-yyyy).

Solution 2

In Google Chrome, this has recently changed. The values displayed to the user are now based on the operating system locale. The readout, so input.value, always returns as yyyy-mm-dd regardless of the presentation format, however.

Way more useful in my opinion.

Source:

http://updates.html5rocks.com/2012/08/Quick-FAQs-on-input-type-date-in-Google-Chrome

Solution 3

The format of the HTML date field is standard. While it is not possible to change this, you can easily convert from a date object to the format you are looking for given your user has JavaScript enabled.

// Converts any valid Date string or Date object into the format dd-MMM-yyyy
function dateTransform(d) {
    var s = (new Date(d)).toString().split(' ');
    return [s[2],s[1],s[3]].join('-');
}

Otherwise you will need to submit in ISO format and implement a server-side solution. Perhaps in time, this could lead to more usage of the standard date format in every locality.

Comments

[ThiefMaster]

dd-mmm-yyyy is not even locale-independent (assuming mmm is "Jan", "Feb", etc.).. So it's rather "sad" if your webapp/scripts require such a format instead of a standard-conforming one which doesn't contain any localized strings.

[Stefan Kendall]

@ThiefMaster: Users who have come to expect 03-FEB-2011 for every date input across an entire application will continue to expect that format. yyyy-mm-dd is neither readable nor expected for US citizens (of which the client was at the time), and the format fails completely for usability if only a month and day are needed, or a day and hour. When convention exists, convention trumps other design principles in many cases for maximizing usability, especially where the client had little churn.

[Stefan Kendall]

Perhaps it's inefficient that clocks are circular and the hands move CLOCKwise, but that's still how they're built. Convention trumps design, and I'm still only going to show 12 hours on my clocks when there are 24 hours in a day, and "Let's meet at 6:30" is ENTIRELY ambiguous. It's a bad root design, but convention trumps other usability principles. I wouldn't put a datetime (ms since epoch) field in a user-facing application ever due to limited and deficient technology. I'd find a workaround. This is no different.

[sonjz]

@ThiefMaster, what a silly comment, who argues the input. Normalize it.

[Aquarelle]

@StefanKendall This has absolutely nothing to do with design. We're talking about code here, not what the user sees. In programming, the most logical date format, at least in LTR languages, progresses from the largest unit to the smallest unit. The pattern would thus be: "yyyy.mm.dd" (although the separator character is arguable, with some popular formats using the hyphen "-" character). The ISO 8601 format follows this pattern. Being a standard, ISO 8601 IS convention which, in this case, trumps design.

[Stefan Kendall]

@Aquarelle "It's a standard" doesn't mean you should use something. I'll never display dates like this. It's awful.