[I left Robert's replies in, even those I didn't have anything to reply to, because Robert originally sent the message only to me (off-list).]<br><br><div class="gmail_quote">On Sun, Mar 15, 2009 at 4:36 PM, Robert J Burns <span dir="ltr"><<a href="mailto:rob@robburns.com">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;"><div style=""><br><div><div><blockquote type="cite"><div class="gmail_quote"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div><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><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.</div>
</div></blockquote><div><br></div><div>Neither do I really. I was simply raising the issue because someone else said they wanted hyphens to be optional (I don't recall which message or who composed it at the moment).</div>
</div></div></div></blockquote><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div style=""><div><div><div></div><br><blockquote type="cite">
<div class="gmail_quote"><br><div>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.</div>
</div></blockquote><div><br></div><div>OK, I see what you mean. That's a fine approach as long as we're clear how the under the hood encoding of dates maps to the human-consumable dates which will be expressed in terms of AD and BC (or CE and BCE). The only concern I have with that approach is that I think authors will often make errors: for example, using -0007 to designate 7 BC instead of 8 BC.</div>
</div></div></div></blockquote><div><br>That is the issue I see with this now. This approach (0000 = 1BC, 0001 = 2BC) is the one that looks, but yes I foresee frequent among authors. If we do allow year 0000 but do not introduce a decal (0001 = 1AD, 0000 = nothing, -0001 = 1BC) we introduce a complication for programs which are going to extract the data for calculations. If we forbid year 0, then we are restricting some authors from using, and we still introduce the problem from the previous sentence.<br>
 </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div style=""><div><div><br><blockquote type="cite"><div class="gmail_quote"><div><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><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><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>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.</div>
</div></blockquote><div><br></div><div>Yeah, the main purpose of the 'datetime' attribute and the ISO 8601-like encoding of dates is for extraction and use elsewhere. The contents of the 'time' element are simply displayed. I would like to see the 'datetime' also used for localized dates regardless, using CSS or another presentational mechanism. However, obviously that's not a part of the HTML5 project (at least not currently). However, there's really no reason to encode the dates in the 'datetime' attribute unless it can be extracted and used in a precise machine-consumable form. Supplementing the date with a keyword prefix or suffix permits even more precise date representation.</div>
</div></div></div></blockquote><div><br>Here is how I would like to see user agents implement the <time> element:<br><br>This software was released on <time datetime='2009-02-15'>February 15th, 2009</time>.<br>
This software was released <time datetime='2009-02-15'>just a month ago</time>.<br>This software was released on <time datetime='2009-02-15'>15/02/09</time>.<br><br>In either of these cases, the content is printed on the correct location in the sentence. When you hover the mouse, a tool tip pop up with the text "February 15th, 2009" or a similar string configured in the user agent preferences or the OS preferences. The date might be decorated in a way similar to <abbr>.<br>
<br>This software was released on <time datetime='2009-03-15'>.<br><br>In this case, the entire <time> tag is replaced by the string "February 15th, 2009" or equivalent, as above. In this case I'm not sure a tool tip would be any useful.<br>
 </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div style=""><div><div><div></div><br><blockquote type="cite"><div class="gmail_quote">
<div><br>  </div><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><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.</div>
</div></blockquote><div><br></div><div>It references year 0000 in a note, but only to remind that 0000 is a leap year according to the leap year rules. It doesn't discuss how it maps to the AD/BC human-consumable dates. Nor does it discuss how to interpret negative years.</div>
<br><blockquote type="cite"><div class="gmail_quote"><br><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</div>
</div></blockquote><div><br></div><div>Personally, I'm fine with that. As I said earlier, someone else (I think only one person) objected to requiring hyphens at all when I wanted to require hyphens only for the non-four-digit year cases. I think he was thinking we should eliminate all of the lower granularity cases (though I do not agree).</div>
<br><blockquote type="cite"><div class="gmail_quote"><div><br>  </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;">
 - 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><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? :)</div></div>
</blockquote><div><br></div>I see. I wasn't saying we should disallow Mayan Long Count calendar only that we could leave it up to another subsequent specification. In that way, the following would indicate the date:</div>
<div> <time datetime='Mayan_12-19-16-03-02'>12.19.16.3.2</time></div><div><br></div><div>Since UAs would not be required by the HTML5 recommendation to support the keyword "Mayan" (only required to support omitted keyword or keyword "Gregorian"), most UAs would simply ignore the machine readable date. Many authors would therefore opt to convert the date to Gregorian before encoding it. However, due to issues like disputed conversions (like those you raise below), HTML5 should support machine readable dates in alternative calendars. In other words UAs MUST support Gregorian calendar dates. UAs must parse calendar prefix keywords. UAs MUST treat dates without a keyword as Gregorian (or with some heuristics to account for mistaken authors). UAs MAY support other keywords (which would be associated with subsequent and separate specifications). These suggestions therefore do not add any burden on HTML5 UAs (except the ability to parse out prefix keywords). However, these criteria properly abstract HTML5 to allow support for alternative calendars without trampling or conflicting with Gregorian dates.</div>
<div><br><blockquote type="cite"><div class="gmail_quote"><div><br>I think the first case is most easily useable, but I do understand your point:<br>  </div><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><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.</div>
</div></blockquote><div><br></div><div>I think the keyword prefix (or suffix or separate attribute value) makes all of this easy to implement and author. HTML5 UAs would only need to parse in such a way that keyword prefixes do not get in the way. HTML5 UAs would be required to recognize the "Gregorian" keyword (the meaning of the "Mayan" keyword might be defined by another specification, but an HTML5 UA would not be required to support it, only to not get tripped up by it or assume it preceded a Gregorian date). I don't think expecting UAs to be aware of an ignorable keyword prefix is any great implementation difficulty, but it does provide a more future-proof design (and is better and clearer for authoring).</div>
</div></div></div></blockquote><div><br>Wah! Suffixes and/or prefixes are harder to read and add a burden on the parser, don't they? A new attribute (such as "calendar='julian'") makes more sense to me.<br>
 </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div style=""><div><div><div></div><br><blockquote type="cite"><div class="gmail_quote">
<div><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></div></blockquote><br></div><div>The reason I was listing those calendars is because they are calendars used as civil calendars in contemporary cultures (unlike the Mayan to my knowledge). I think this suggests that a specification like HTML5 aimed at the Worldwide Web should at least make room for those calendars (even if it doesn't define them). To my knowledge the Mayan is rather unique. Most of the others require representation much the same as the Gregorian and Julian calendars: year, month, day. They might still require a separate specification to define what those dates mean, what eras are used, how dates before one are handled, and perhaps how they convert to the Gregorian calendar (since that is usually the presumed calendar under the hood of any operating system). Most of these calendars have more complex rules for year and month length than the Gregorian/Julian calendars (though the Egyptian calendar is quite simple and is probably the precursor to the Julian and Gregorian calendars). So since the representation properties are mostly the same for these calendars it is easy to represent them in the form KEYWORD_YYYY-MM-DD. </div>
<div><br></div><div>To me ISO 8601 makes two contributions: 1) provides a way to unambiguously represent Gregorian dates (though with a keyword added the same method can easily be expanded to represent virtually any calendar system date imaginable); 2) reiterates the specification of the Gregorian calendar already in existence pre ISO. The first contribution can be easily expanded to represent dates in any calendar system. The second contribution can easily be expanded to 1 AD with little controversy. However, the addition of a calendar system keyword allows greater flexibility down the road without placing any appreciable burden on UAs today.</div>
<div><br></div><div>Take care,</div><div>Rob</div></div></div></blockquote></div><br><br>This whole debate over non Gregorian calendars is far from me. I have never even used dates other than Gregorian in my whole life (that is, before the discussion on this list) and thus it is very difficult for me to tell what method is the best one. I do understand there is a need for a method, though.<br>
<br>From what you say, and from some more thinking on my part, the following could make sense:<br><br>Have a new attribute to tell what calendar is used. The datetime attribute's value is a date on the calendar specified in the new attribute. UAs are required to understand Gregorian (the absence of the new attribute means we are using Gregorian). They *may* understand other calendar, but only for the purpose of showing them correctly (or any other task which has nothing to do with conversion).<br>
<br>Does that make sense? Is it what people need? It is useful? Is it easy to implement? Do you believe in the Yeti?<br><br><br><br>