I'm adding myself, as creator of this "bug".

This is an enhancement request, not a bug.

It could help to enable backwards compatibility.

Browsers can allow the user to fill in any format, it just has to turn the date into a canonical format for submission. Isn't this enough to solve your use cases?

EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document:
   http://dev.w3.org/html5/decision-policy/decision-policy.html

Status: Did Not Understand Request
Change Description: no spec change
Rationale: see comment 3

The main problem come from the fact that we may need backward compatibility. If a website already exists, have a particular date format input in accordance with the language, but you want to upgrade it to HTML5, the new date format may be a problem, both for the user, and for adapting the date input.

Let's take an example (this is totally fictional) :
A travel broker in France may need to convert its website, to have html5 control. It already have date inputs, in type="text". And because we are in France, everyone would type the today date as «28/08/2010».

But if (let's say, the company want to go on the whateverPhone hype) it asks to a webdesigner to convert it as html5 input, it won't be a easy task for everyone :
1- the existing code would be broke away in input : it still waiting for a DD/MM/YYYY format, but instead will get YYYY-MM-DD
2- clients having legacy browsers would have to put date in a format understood only by accountants and sql-specialists. This second issue is a non-go.
3- Javascript runaround may be problematic, erratic, for any reasons. (By example, disabled people)

Some CMS, backoffices, extranet, use a kind of datetime in a format like «28/08/2010 09:33». Any conversion would be problematic if a important part of the users should convert themselves to «2010-08-28Z09:33:45» (I don't even think about the TZ aspect of this problem), and the aged source code of these websites are now terra icognita.

To deploy and popularize HTML5 may be easier.
That's why i think <input type="date" /> and datetime should allow a pattern="" parameter. The french-date example could be pattern="\d{2}/[01]\d/\d{4}" 

Sorry my bad EN locale.

(In reply to comment #5)
> The main problem come from the fact that we may need backward compatibility. If
> a website already exists, have a particular date format input in accordance
> with the language, but you want to upgrade it to HTML5, the new date format may
> be a problem, both for the user, and for adapting the date input.
> 
> Let's take an example (this is totally fictional) :
> A travel broker in France may need to convert its website, to have html5
> control. It already have date inputs, in type="text". And because we are in
> France, everyone would type the today date as «28/08/2010».
> 
> But if (let's say, the company want to go on the whateverPhone hype) it asks to
> a webdesigner to convert it as html5 input, it won't be a easy task for
> everyone :
> 1- the existing code would be broke away in input : it still waiting for a
> DD/MM/YYYY format, but instead will get YYYY-MM-DD
> 2- clients having legacy browsers would have to put date in a format understood
> only by accountants and sql-specialists. This second issue is a non-go.
> 3- Javascript runaround may be problematic, erratic, for any reasons. (By
> example, disabled people)
> 
> Some CMS, backoffices, extranet, use a kind of datetime in a format like
> «28/08/2010 09:33». Any conversion would be problematic if a important part
> of the users should convert themselves to «2010-08-28Z09:33:45» (I don't even
> think about the TZ aspect of this problem), and the aged source code of these
> websites are now terra icognita.
> 
> To deploy and popularize HTML5 may be easier.
> That's why i think <input type="date" /> and datetime should allow a pattern=""
> parameter. The french-date example could be pattern="\d{2}/[01]\d/\d{4}" 
> 
> Sorry my bad EN locale.

Your issue is probably not client side.
Indeed, it's up to the browser to show a localized date picker. That means, if you are using a french version, the browser should show dates in the french format. However, the DOM will still return the date in the specified way if you call .value.
However, your form will no longer send the date in the french format but in the specified one so some changes may be needed server side to be sure the new format is correctly handled. If the server side code is done correctly that should not be a major issue.

By the way, using the pattern attribute would not have solve the problem. Considering the pattern attribute has no semantic, where should be put the day, month and year when selected with the date picker?

EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document:
   http://dev.w3.org/html5/decision-policy/decision-policy.html

Status: Rejected
Change Description: no spec change
Rationale: In the scenario described in comment 5, you would just have the server accept both the localised format for legacy browsers, and the ISO format for new browsers. I don't see the problem.

*** Bug 11322 has been marked as a duplicate of this bug. ***