This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Created attachment 1049 [details] The proposed spec for National Calendars support in HTML5 In the new types for input field in HTML5 ( date , datetime and datetime-local ) only gregorian calendar format is supported. Non-gregorian calendars like Hijri Calendar and Hebrew Calendar needs to be supported. Attached the proposed spec
Similar to all the other new input types, the *value* of the input must be in the gregorian calendar, but the interface displayed to the user can be anything at all. It could be a text box, a gregorian calendar picker, or some other calendar. This is entirely up to the browser. Note that many of us do not have the ability to easily read Word docs. It would be helpful to instead get the doc as text, html, or even pdf. All of these should be options when you save from Word.
*** This bug has been marked as a duplicate of bug 10198 ***
The problem with relying on a single calendar model is that conversion between calendaring systems may rely on additional information that may not be present and can prevent either general conversion OR inversion. Consider the conversion of a datetime that occurs early on a day in a lunar calendar, which is really late in the day on the gregorian. That's a reasonably well understood conversion to make. HOWEVER, it's impossible to go backwards without knowing the actual times for sundown and WHERE the date conversion is taking place. See references such as <http://www.amazon.com/Calendrical-Calculations-Millennium-Edward-Reingold/dp/0521777526> for more details.
Do you contest that this is a duplicate? *** This bug has been marked as a duplicate of bug 10198 ***
I suggest that this particular instance of the issue has a GREATER AMOUNT of feedback on the issue, including a complete proposal on resolution of the issue. Therefore, I would leave this particular one open and leave the other one closed.
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: The calendar that is used for submission is arbitrary — we could equally have used the Unix time_t convention as the calendar. If you want to know where the date is to be converted for when converting to a calendar in which physical location is relevant, then you should include location as a separate field.