Re posted because accidentally posted offline (well even I can do mistakes...)<br><br><div class="gmail_quote">---------- Forwarded message ----------<br>From: <b class="gmail_sendername">Tom Duhamel</b> <span dir="ltr"><<a href="mailto:tom420.duhamel@gmail.com">tom420.duhamel@gmail.com</a>></span><br>
Date: Sun, Mar 15, 2009 at 1:50 AM<br>Subject: Re: [whatwg] <time><br>To: Robert J Burns <<a href="mailto:rob@robburns.com">rob@robburns.com</a>><br><br><br><div class="gmail_quote">(I saddly stripped down this very long post to only the parts relevant to
my replies, but really if you are currently reading this from an
archive 10 years from now find and read the original post, Rob really
has a lot to say and I'm looking forward to read more of his ideas and
opinions)<div class="im"><br>On Sat, Mar 14, 2009 at 8:01 PM, Robert J Burns <span dir="ltr"><<a href="mailto:rob@robburns.com" target="_blank">rob@robburns.com</a>></span> wrote: <br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">

<br><div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Use ISO 8601 with the following provisions:<br>
- Allow all four digit years, positive and negative<br>
</blockquote>
<br></div>
We cannot agree on this unless we go beyond ISO 8601 and define how those representations map to BC/BCE while also keeping consistent leap year rules in place (note this is an area that does require some calendar expertise).<div>


<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
- Allow lower granularity dates: 2009-03-14, 2009-03, 2009<br>
</blockquote>
<br></div>
Agreed<div><br>
<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
- Allow ranges: 2009-03-01/2009-03-14<br>
</blockquote>
<br></div>
Agreed<div>
<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
- Allow only extended format: 2009-03-14 (rather than 20090314) which will help with simplification and future extensions<br>
</blockquote>
<br></div>
This may be more controversial. I think we could allow the omission of hyphens for years of four digits. Others have contended that we might also allow the omission of hyphens always if we omit support for ordinal dates (e.g., YYYY-DDD).</blockquote>

</div><div><br>I don't see a use case for YYYY-DDD, and haven't seen anyone propose one yet. I really believe that would be of no use for us. However, see my comment below about why I think extended format should be mandatory.<br>

 </div><div class="im"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div><br>
<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
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>
</blockquote>
<br></div>
I would add that keyword support for alternate calendars is an important part of keeping options open for HTML6 and also to help reduce authoring errors.<div>
<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
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.<br>
</blockquote>
<br></div>
It is important because we want dates before 0001-01-01 to be encoded unambiguously.  If we don't address such issues we need to limit ourselves to 0001-01-01 and later.<div>
<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
I think it should be allowed. Historians deny the existence of year 0, but astronomers use it.<br>
</blockquote>
<br></div>
It isn't a matter of denial or belief. This is an issue of precisely defining a Gregorian calendar to apply to the past: a calendar which was defined in 1582 with only the future in mind. ISO 8601 could have stepped in an further defined the Gregorian calendar but it punted. So no one is denying the year 0000 exists. The question is whether the Gregorian calendar should call the year before 1 AD, "year 0". Could you provide some reference to astronomy's used of a year 0 between 1 AD and 1 BC (for example the Starry Night astronomical software I use does not have a year 0 between 1 AD and 1 BC. I often see such claims made, but I've never seen such definition/use of a specialized Gregorian calendar).</blockquote>

</div><div><br>Again I do not claim any expertise here, but I was always told astronomers use the year 0 because it makes calculations easier. They don't use BC or AD notation, but instead use positive and negative signs (+2009, -54...). They do decal from historic dates. That is, what they call year -1 is what historians call 2BC.<br>

<br>For a starter: <a href="http://en.wikipedia.org/wiki/Year_0" target="_blank">http://en.wikipedia.org/wiki/Year_0</a><br>(Before someone debates over Wikipedia, I have never considered Wikipedia as THE reference, but always thought it was a good starting point, from which one serious enough can go an do more researches.)<br>

 </div><div class="im"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div><br>
<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
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?<br>
</blockquote>
<br></div>
If I understand current proleptic Gregorian calendar use correctly (such as that used by astronomers) the implication is that HTML will not match the other uses of that calendar. ISO 8601 has unambiguous leap year rules which are to be applied to 000 and negative years as well. If we accept year 0, then -0001 would mean 2 BC. That's fine, but we need to make it clear to authors and there's some concern authors would make the mistake of thinking -0001 was instead 1 BC.</blockquote>

</div><div><div class="im"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div><br>
<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
HTML parser does not perform math over dates, it merely displays information based on what an author instructed.<br>
</blockquote>
<br></div>
However, if the UA displays the information in a non-machine readable
form, how does it make that conversion for presentation purposes. Does
0000-01-01 get displayed as 1 January 1 BC? Or as 1 January 00?</blockquote><br>
<br></div>Since I always thought of HTML as a method of enclosing content for the purpose of display only, my thinking was that it was not important whether or not year 0 existed or not. I thought that an author would put -54-03-17 and the user agent would show "March 17th, 54 BC". Then if one decides he likes the year 0, he would put 0000-12-25 and the user agent would print "December 25th, 0". The browser would just print what we told him to print, without an actual understanding of what it means.<br>

<br>But after reading your comments above and below (in particular the place where you mention the possible use of a HTML file for something other than displaying to a reader), and checking a few more pages on the web, I now understand it does in fact matter whether or not a year 0 is used.<br>

 </div><div class="im"><div></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div><br>
<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
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.<br>
</blockquote>
<br></div>
Could you cite specifically where you get that from ISO 8601:2000? I'm looking at ISO 8601:2004 and don't see a clear indication of that anywhere.</blockquote></div><div><br>Actually never mind this. I have never read the actual ISO, but rather some other website which gives a detailed, human readable summary of the ISO. I will however read the actual ISO very soon now, as I got an interest in it now but haven't had time yet. I will return to that if I then fell the need to. I will take that you have actually read the ISO and haven't found a mention of year 0.<br>

 </div><div class="im"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div><br>
<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Most, I believe, will want year -0004 = 4BC (and this is what I'd suggest).<br>
</blockquote>
<br></div>
If -0004 equals 4 BC then that may require leap year rule adjustments to match other proleptic Gregorian calendars (where -0005 would be a leap year instead). Again the problem is that we do not have a definitive standard to reference for a proleptic Gregorian calendar, especially for year before 1 AD.<div>

<br>
<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
- 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>
</blockquote>
<br></div>
That looks fine to me. Others have suggested we still allow hyphenation omission (which works if we exclude ordinal dates like YYYY-DDD). This would also then allow: "100000101" to represent 1 January 10,000.</blockquote>

</div><div><br>The reason I suggested that we only allow extended version (with hypens), is for the following two reasons: Allow both lower granularity dates and more than four digit years. If I use the date "99120412". It is "April 12th, 9912" or "April of the year 991204" (lower granularity with no day) or even just "The year 991204"? With mandatory hypens, it becomes clear: 9912-04-12<br>

 </div><div class="im"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div><br>
<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
- 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>


</blockquote>
<br></div>
We don't need to concern ourselves with how the Mayan Long Count calendar works. </blockquote></div><div><br>No we don't but this is an example of a non Gregorian calendar which some authors might want to use on a web page<br>

<time calendar='mayan' datetime='2009-03-14'>12.19.16.3.2</time><br><time calendar='mayan' datetime='12.19.16.3.2'>12.19.16.3.2</time><br>Get what I mean? :)<br>I think the first case is most easily useable, but I do understand your point:<br>

 </div><div class="im"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">First of all, the concerns raised are largely over Julian and Revised Julian calendars. Other calendars of concern include Hebrew, Islamic and Buddhist all of which are used today as civil calendars. The other concern is that without clearly defined Gregorian and other calendars (and for some periods in history all of these calendars lack clear standards that map the representation unambiguously to a specific day on the Earth), it is more accurate and precise for authors to encode a date within the precise calendar than to attempt conversion (which is a lossy operation in that case). Conversion is better handled at runtime by UA algorithms that keep constant with the state of standards (but that requires some kind of keyword differentiation of non-Gregorian and even clearly Gregorian dates).</blockquote>

</div><div><br>A mesoamerican historian might prefer to use the mayan long count without wanting to convert to a Gregorian date for the purpose of marking up with HTML. Also, to cover your other point, the Mayan long count calendar is generally aligned on August 11, 3114 BC, but some other historians think this date if off by a few days, so perhaps a future generally accepted epoch date might be different. All the points to you, your opinions seems very reasonable to me. Now my concern is still the same, I wonder how easy it would be to implement (actually, I think it would be very difficult). But well, I don't disagree that having access to non Gregorian calendars is very useful. But here we need to find a way, one which is easier to implement, and still easy enough for authors.<br>

<br>What about those 'other calendars of concern'? Are they reasonably compatible with Gregorian, or so much different that my example of the Mayan long count becomes a good one? I know nothing about those, but I fear it's the later.<br>

 </div><br></div><br>
</div><br>