<br><br><div class="gmail_quote">On Sat, Mar 14, 2009 at 8:23 AM, Smylers <span dir="ltr"><<a href="mailto:Smylers@stripey.com">Smylers@stripey.com</a>></span> wrote:<br><blockquote style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;" class="gmail_quote">
<div>only doing the simplest possible<br>
thing for now, acknowledging that that doesn't meet all desirable <br></div></blockquote><blockquote style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;" class="gmail_quote">
<div><br>
scenarios, and leaving everything else for HTML 6. <br></div></blockquote><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">I'm proposing that we don't hold up that standard while trying to solve<br>

a hard problem.<br>
<br>
(I'm still in favour of people working on it to solve it.  And if there<br>
happened to be a consensus for a (partial) solution now I wouldn't be<br>
against including it.  But that isn't where we are.)<br>
<font color="#888888"><br>
Smylers<br>
</font></blockquote></div><br><br>Wait. HTML 5 is a work performed over a decade, which we are only in the middle. We are certainly no delaying anything here. HTML 6 would be another decade of work. What we don't do now, we won't do for 15 years.<br>
<br>We don't have a consensus yet, and that is why I joined the debate. Because I feel my opinion is important, although I feel people much more knowledgeable then I am are going to show how wrong I am :P<br><br>I feel we are close to a 'partial' consensus, to reuse your term. Here is what I feel most people agree on:<br>
<br>Use ISO 8601 with the following provisions:<br>- Allow all four digit years, positive and negative<br>- Allow lower granularity dates: 2009-03-14, 2009-03, 2009<br>- Allow ranges: 2009-03-01/2009-03-14<br>- Allow only extended format: 2009-03-14 (rather than 20090314) which will help with simplification and future extensions<br>
<br>I'm not sure many have arguments against any of the above. Sorry if I missed anything. I don't claim we have actually reached a consensus.<br><br>Here are items which we are debating over, with my opinion on these:<br>
<br>- Allow year 0000 or not?<br>Actually I don't see why it's important. I think it should be allowed. Historians deny the existence of year 0, but astronomers use it. What if year 0 is accepted as a valid date for the purpose of HTML, and then not used by authors? It would become available for those authors who use year 0, and ignored by others. Whats the implication? HTML parser does not perform math over dates, it merely displays information based on what an author instructed.<br>
<br>Here his the only debate I see over this:<br>ISO 8601:2000 and above suggest that year 0000 be used and be considered year 1 BC, and then -0001 is 2 BC, etc. Most, I believe, will want year -0004 = 4BC (and this is what I'd suggest).<br>
<br>- Allow 5 or more digit dates? Like year 10,000 or year 100,000 BC?<br>It's feasible: 10000-01-01, or -100000-01-01 (which is more likely to be used with lower granularity I guess). I don't think this is going to give parsers a greater complication.<br>
<br>- Allow non Gregorian calendars?<br>There are actually two debates on this issue. One is whether to allow other calendars as the datetime attribute values, the other is to always have the datetime attribute value specified as a Gregorian date while adding a new attribute which would indicate what calendar is used for the content. I would personally go against the use of any non Gregorian calendar at all, since I do believe the use cases are too few. However if it is considered that the use of non Gregorian is to be supported, I would go with the later solution (allow non Gregorian as the content only, and have the datetime attribute always defined as a Gregorian date), since that would not put much complication on the parser (which does not have any calculation/conversion to perform, leaving that to the author). The new attribute would then be used by the browser to tell what calendar is used, but the datetime attribute is still used to indicate to the user the Gregorian equivalent. I do see too many problems with accepting non Gregorian as the value of the datetime attribute: too many calendars are way incompatible (try to represent a Mayan Long Count calendar),...<br>
<br>Those are pretty much the current debates, as I see it. Please feel free to add anything I missed. My current recommandation would be that we try to come to an agreement on current debates, rather than come up with more debates. We have already determined that none of use are calendar experts (and I have already proven I'm far from one), but I think we can come up with something that would give enough flexibility to anyone without giving much restrictions. One idea that comes to mind (if ever allowed by the current HTML draft, I am no sure) could be to force parsers into a minimum set of rules (i.e. accept at least 4 digits for years) while giving them the freedom to decide whether or not to implement extended features (accept any number of digits for years). Most popular browsers would probably implement everything, while smaller ones (those with more restrictions, such as cell phone browsers) could go with the minumem (and still cover 95% of use cases) while leaving the extended, more demanding features (although I don't feel my long year example is a good one to represent a 'demanding feature').<br>