While I do not wish to discriminate against any non-western culture, it should be noted that there are lots of calendars besides the Gregorian, which makes me skeptic about this proposal.

http://en.wikipedia.org/wiki/Calendar#Currently_used_calendars

Adding native support for these in HTML5 would need lots of research and consideration. E.g. what would the toolchains look like, how would the dates be presented in different locales and languages, etc, etc.

And what calendars should be included?

Outside of HTML there are very few tools that support other dates than the Gregorian, e.g. I've yet to see a database that has a native date format that is appropriate for the Islamic, Chinese, Hebrew or Indian calendar.

Presentation is a different factor. Outlook supports Arabic, English, Hebrew, Hindi, Chinese, Japanese, Korean, and Thai calendars.

http://office.microsoft.com/en-us/outlook-help/display-an-alternate-calendar-HA010166885.aspx

Can you elaborate on "business needs"? Is this about UI or submission format for instance? In general we do not make changes to the specification without clear use cases.

It should be possible for browser vendors to implement support for alternative calendars based on the user's locale settings. This would only require user interface changes, allowing the browser to do conversion to and submission in the Gregorian calendar date format. This doesn't require any changes to HTML, either in the markup or submission formats.

To limit the scope of this issue i think it should be regarded only in terms of presentational localization and forgoing being wrapped up in an orthogonal and far less important issue of text-encoding date\time values. The latter is only of concern for programmer client-server communication and without any real standards in this area is not a frontier which HTML should be concerned with.

The presentational aspect of localization is of far greater importance as this is for communicating the representation of values for end users who are nontechnical and also shouldn't be expected to be multi-cultural or multi-lingual or of capability in deciphering localizational discrepancies within browser-rendered html documents.

As noted, the presentational rendering of date\time values is well trodden ground in other programming languages, systems and applications. This tends to be implemented through a locale-based system, however BFP-47 together with Unicode extensions provide the necessary means for defining full language, script, territory, calendar and collation information. For example, the following is valid BCP-47 language tag as well as a valid Unicode locale identifier:

de-Latn-DE-u-ca-gregory-co-phonebk

Which is interpreted as:

Language: German("de")
Script: Latin("Latn")
Territory: Germany("DE")
Calendar("ca"): Gregorian("gregory")
Collation("co"): Phonebook("phonebk")

This means that the following should be all that is required for a date input field to be formatted by the browser within the islamic calendar scale:

<input type="date" lang="en-u-ca-islamic"/>

This information is available within BCF-47 and already within specification and thoroughly implemented in other languages\systems.

This bug is related to 13408:
https://www.w3.org/Bugs/Public/show_bug.cgi?id=13408

Unicode Locale Extension (‘u’) for BCP 47:
http://cldr.unicode.org/index/bcp47-extension

UTR35 (CLDR/LDML):
http://unicode.org/reports/tr35/tr35-15.html

Java BCP-47 Extension Support:
http://docs.oracle.com/javase/tutorial/i18n/locale/extensions.html

It's not clear if this is for the over-the-wire submission format or the user interface; can you elaborate?

This should only apply for formatting and parsing the value to\from a user interface display. 

The transmission format should retain the ISO 8601 representation value so as to remain unambiguous and remove the need for any additional encoding declaration within the request. This is an internet standard and i am unaware of any actual alternatives to this (other than the subset rfc3339). Since the consumer of transmitted values is servers and developers this has little impact within multi-cultural uses and even the english language is almost a prerequisite for programming let alone using a gregorian calendar.

The only limit with this is that dates before the common era will not be encodable, however that a user is able to interact with dates\times within a chosen calendar scale satisfies the overwhelming majority of use cases and represents far greater authoring potential than currently forcing display within the gregorian calendar.

With further thought this approach may contain potential for greater applicability in scope as currency and collation information is also specifiable within these tags. 

A new currency input could be added with automatic currency symbol substation and formatting.

Collation could be used for automated ordering of lists which are dynamically populated on client-side.

The additional benefit to full support of this feature is that this is an extensive standard repository of locale data which is already managed and integrated into operating systems and programming languages. This should make implementation and maintenance a relatively simple process and without introducing any overhead into html or specification authorities.

If we're just talking about the UI, then the spec already suggests that browsers use locale-specific UIs based on the page locale for things like date and number controls.

Sorry for the lateness of the reply, i've been getting 'snowed' under recently...

Yes this is only for presentational rendering and it is already suggested in spec that the "lang" attribute be used as declaration for localization.

I suggest that in order for the potential to be realized for authors and browsers that an additional example is added specifically noting the use of the unicode extension tags for calendar declaration. This was unapparent prior the this bug being opened and investigated, and i expect support and use in this area is otherwise non-existent.

The unicode extensions are invalid without at least a primary language subtag and as such require a language declaration in order to be well formed and applicable. 

The format of the note could be represented as follows in illustrating the Islamic New Year of 1434 AH in the Arabic language and with regards to the conversion required from the ISO time encoding:

<input type="date" lang="ar-u-ca-islamic" value="2012-11-15"/>

For more examples, see how this is implemented by Eclipse for representing calendars in multiple languages:

https://bugs.eclipse.org/bugs/show_bug.cgi?id=243270

There is also ongoing work in the globalization extension to javascript which will tie in directly with this:

http://html5labs.interoperabilitybridges.com/prototypes/javascript-ie-extensions/javascript-extensions/info

This bug was cloned to create bug 17808 as part of operation convergence.

;; This buffer is for notes you don't want to save, and for Lisp evaluation.
;; If you want to create a file, visit that file with C-x C-f,
;; then enter the text in that file's own buffer.

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 change
Rationale: The date and time format used in HTML5 is for over-the-wire
values; UAs are free to expose locale-specific UI for date inputs.

That said, exposing a method for Web authors to request that the UA use
a particular locale's calendar in its date input UI is a feature we
could consider for inclusion in HTML.next.

(In reply to comment #10)
> Status: Rejected
> Change Description: No change
> Rationale: The date and time format used in HTML5 is for over-the-wire
> values; UAs are free to expose locale-specific UI for date inputs.
> 
> That said, exposing a method for Web authors to request that the UA use
> a particular locale's calendar in its date input UI is a feature we
> could consider for inclusion in HTML.next.

I think you may have misunderstood the recommendation from this bug. This is essentially a no-change for normative specification and i agree 100% with your first statement.

UA's are free to define locale-specific UIs so there is nothing to punt on to HTML.next

This is only an awareness issue which is why a specific example is recommended, but not even necessary. I was going to suggest that this be discussed at TPAC to highlight that browser vendors for other regions can use this to provide regional-specific browsers. There is no requirement for any browser to implement anything unless they are providing universal or region-specific browsers. The over-the-wire encoding is always ISO 8601.