Surely this is a presentation issue which should be addressed using CSS? Maybe a date-format property which takes a formatting string of some kind?

It's not the first time I see someone confused about format of date UI and internal date representation.

I think the spec needs to have big flashing banner that says "This is format submitted to the server. Browsers are not required to *display* it like that, and can use localized date format in the UI."

As Kornel says, the specified format is the format that the *data submitted to the server* must be in.  It has absolutely nothing to do with the actual display of the date or time; browsers are free to display them to the user in whatever format they wish.

The original request was for the web developers to be able to determine the date and time format, not have it be controlled by the browser.

(In reply to comment #4)

Sorry if I misunderstood.

In that case, why is it important to override implementations?

I'm assuming that browsers will read preferred date format from system's locale, so Large USA Corporates and Government departments would get date displayed in mm/dd/yyyy format and 12-hour time automatically.

(In reply to comment #5)
> (In reply to comment #4)
> 
> Sorry if I misunderstood.
> 
> In that case, why is it important to override implementations?
> 
> I'm assuming that browsers will read preferred date format from system's
> locale, so Large USA Corporates and Government departments would get date
> displayed in mm/dd/yyyy format and 12-hour time automatically.

I'm not the original filer. Unfortunately, it's one of those from the inline comments, which means the person is now disconnected from what is happening with their request. I hope they follow up on the discussion.

I believe, though, that what you're saying is not what the original filer was asking. They were asking for the ability to specify something other than have the browser default to system locale. At least, that's how I read:

"Both date and time inputs should have the option to use a variety of
international formats (not just the browser locale)..."

Shelley is right -- I think the contributor was confused about display vs. internal formats, but he's still asking for the ability to choose specific output formats other than the browser locale.  This is probably a good feature to have, but as Philip says in comment 1, it's probably a CSS thing.

(In reply to comment #7)
> Shelley is right -- I think the contributor was confused about display vs.
> internal formats, but he's still asking for the ability to choose specific
> output formats other than the browser locale.  This is probably a good feature
> to have, but as Philip says in comment 1, it's probably a CSS thing.

I don't believe that can be reliably inferred from the OP.  The OP had the standard confusion between displayed value and submitted value.  The request for more control over the displayed value is sufficiently vague that it can easily be interpreted to be satisfied by the existing spec text.

However, if we assume that the OP *was* asking for direct author control over the display of dates and times, then, well, that's a horrible idea.  The entire *point* of the datetime inputs is to offer the display in whatever fashion the user most desires.  Giving control over this to the author defeats that and is directly and explicitly bad for i18n.  If I were European and was used to seeing dates as "DD/MM/YYYY", I would *not* want an ignorant American developer setting the displayed value to use the format "MM-DD-YYYY", *especially* if I'm used to other sites leaving the displayed value to the default so the browser respects my locale conventions.

(In reply to comment #8)
> However, if we assume that the OP *was* asking for direct author control over
> the display of dates and times, then, well, that's a horrible idea.  The entire
> *point* of the datetime inputs is to offer the display in whatever fashion the
> user most desires.  Giving control over this to the author defeats that and is
> directly and explicitly bad for i18n.  If I were European and was used to
> seeing dates as "DD/MM/YYYY", I would *not* want an ignorant American developer
> setting the displayed value to use the format "MM-DD-YYYY", *especially* if I'm
> used to other sites leaving the displayed value to the default so the browser
> respects my locale conventions.

I think consistency within a site is much more expected and valuable than consistency between sites, for things that visually appear to be part of the site.  More generally, lack of styleability is a clear deficiency of the new HTML5 inputs compared to existing solutions, and we might need to give authors a lot of control before the inputs will be widely used.

However, I don't think there's any way to say for sure what's needed until browsers have basic implementation down.  In all likelihood, there will be some companies or governments that demand some particular formatting, but it will probably be the same formatting that their browser uses by default, and they won't realize people in other locales will see things differently, so they won't care.

I'd reclose the bug as LATER, but I'm not actually sure people other than the editor should really be resolving bugs that aren't clearly garbage.

(In reply to comment #9)
> (In reply to comment #8)
> > However, if we assume that the OP *was* asking for direct author control over
> > the display of dates and times, then, well, that's a horrible idea.  The entire
> > *point* of the datetime inputs is to offer the display in whatever fashion the
> > user most desires.  Giving control over this to the author defeats that and is
> > directly and explicitly bad for i18n.  If I were European and was used to
> > seeing dates as "DD/MM/YYYY", I would *not* want an ignorant American developer
> > setting the displayed value to use the format "MM-DD-YYYY", *especially* if I'm
> > used to other sites leaving the displayed value to the default so the browser
> > respects my locale conventions.
> 
> I think consistency within a site is much more expected and valuable than
> consistency between sites, for things that visually appear to be part of the
> site.  More generally, lack of styleability is a clear deficiency of the new
> HTML5 inputs compared to existing solutions, and we might need to give authors
> a lot of control before the inputs will be widely used.
> 
> However, I don't think there's any way to say for sure what's needed until
> browsers have basic implementation down.  In all likelihood, there will be some
> companies or governments that demand some particular formatting, but it will
> probably be the same formatting that their browser uses by default, and they
> won't realize people in other locales will see things differently, so they
> won't care.
> 
> I'd reclose the bug as LATER, but I'm not actually sure people other than the
> editor should really be resolving bugs that aren't clearly garbage.


I agree that it is difficult to determine author and developer acceptance of the form controls until we have wider implementation. We still do not have a date implementation in the two browsers people use most, Firefox and IE, and the implementation in the other browsers is still undergoing change.

A LATER status would enable us to re-visit this issue once there is wider implementation.

One quick PS

Of course, at a later time, it is going to be difficult to get any changes into the spec, or implementations. In addition, there is a very real possibility that developers and web site authors will just reject the HTML5 form elements (or many of them) in favor of existing libraries, making acceptance of even changed specs and implementation that much less guaranteed. 

In the end, if the people don't use the HTML5 functionality, because it's too restricting or too inflexible, it doesn't matter who implements what.

Checked in as WHATWG revision r5761.
Check-in comment: Date/time form controls: Add notes saying that the UI doesn't have to match the submission format. Some day we'll add graphics to make it more obvious, but for now I don't want to bias implementations.
http://html5.org/tools/web-apps-tracker?from=5760&to=5761

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: see above.
Rationale: I've tried to clarify the spec as suggested in comment 2, but beyond that I don't understand exactly what is being requested here.

Original poster: please feel free to reopen the bug as described in the "EDITOR'S RESPONSE" paragraph above.

Others: please file new bugs if you have specific ideas or suggestions stemming from the discussion above.

mass-move component to LC1