This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
This was was cloned from bug 15278 as part of operation convergence. Originally filed: 2011-12-20 11:34:00 +0000 Original reporter: Ghada Selim <ghadas@eg.ibm.com> ================================================================================ #0 Ghada Selim 2011-12-20 11:34:00 +0000 -------------------------------------------------------------------------------- Created attachment 1053 [details] Proposed solution for Islamic Calendar support Referring to HTML5 specifications on http://dev.w3.org/html5/spec/, there are new date and time values added to the type attribute of the input element (date, month, week, time, datetime, datetime-local). These types follow the Gregorian calendar format while there are more calendars that are widely used in some regions ( for example the Islamic (Hijri ) Calendar which is the official calendar in Saudi Arabia and other ME countries). There are business needs that require national calendars so some libraries like ICU4j and Dojo toolkit added the support for national calendars. Please find attached a proposal for adding the support of the Islamic Calendar in HTML5 specifications. ================================================================================ #1 Lars Gunther 2011-12-20 16:14:12 +0000 -------------------------------------------------------------------------------- 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 ================================================================================ #2 Anne 2011-12-20 16:18:24 +0000 -------------------------------------------------------------------------------- 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. ================================================================================ #3 Lachlan Hunt 2011-12-20 16:55:03 +0000 -------------------------------------------------------------------------------- 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. ================================================================================ #4 Cameron Jones 2011-12-21 16:39:07 +0000 -------------------------------------------------------------------------------- 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 ================================================================================ #5 Ian 'Hixie' Hickson 2012-01-12 23:00:56 +0000 -------------------------------------------------------------------------------- It's not clear if this is for the over-the-wire submission format or the user interface; can you elaborate? ================================================================================ #6 Cameron Jones 2012-01-13 17:48:17 +0000 -------------------------------------------------------------------------------- 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. ================================================================================ #7 Ian 'Hixie' Hickson 2012-02-01 00:40:39 +0000 -------------------------------------------------------------------------------- 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. ================================================================================ #8 Cameron Jones 2012-02-08 14:29:46 +0000 -------------------------------------------------------------------------------- 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 ================================================================================
I don't think the calendar rendering should be based on lang="". At some point we'll probably add a locale="" which might be used to decide on the calendar (see bug 17859), but that's not likely to happen soon.