There have been a lot of discussion around the <time> element lately, and I followed most of it since I'm pretty interested in this element, and frankly I believe it will be very useful in the future. However, I too have opinions around this. I do agree with some argument presented before, and disagree with others. This post is not meant to be very long, I just wanted to state a bit about my opinion, although I don't consider myself knowledgeable enough to discuss the entire set of issues.<br>
<br>Precise Date/Time<br><br>My understanding is that the current protocol will only accept this format for a valid precise date:<br>2009-03-09<br>And this format for a valid precise time:<br>15:10 or 15:10:19<br><br>My opinion is that all the following dates are precise:<br>
2009<br>2009-03<br>2009-03-09<br><br>There are numerous reason to use dates which are not very precise, but are still precise nevertheless. I'm going to release the new version of my current project in <time datetime="2009-04">April</time> but I cannot tell as of now the exact day of the release.<br>
<br>The later is more precise, but the three are all precise in my opinion. On the other hand, those are NOT precise dates:<br>Last year<br>About a month ago<br>Last summer<br>Somewhere during the summer of 2010<br><br>The same would apply to times. "This morning", "I'll be there in an hour" are not precise.<br>
<br><br>Gregorian Calendar<br><br>There have been requests that the <time> element accepts dates expressed in other calendars than Gregorian. This is not doable, although I do understand those who mentioned this, mostly about the Julian calendar.<br>
<br>Julian for instance cannot give a precise date (we are not considering the fact that it was not precise enough) because it was based on some events in history, often the arrival of a new leader. For example, when Bush was elected in Nov 2000, we would have considered that year to be the new year 1. Thus Bush was elected in November 1, re-elected in November 5. Then Obama was elected in November 9 of the Bush era, which was also Novemember 1 of Obama era.<br>
<br>Wikipedia is often mentioned as a use-case, but based on my own experience (I am not an historian or anything, so my use of Wikipedia for historical events is sporadic) they most usually convert Julian dates to the Gregorian calendar. Julius Caesar died in 14 BC, not 52 of the Julius era on the Julian calendar (or whatever date it would convert to).<br>
<br><br>Historic Dates<br><br>From my understanding of the current draft, the earlier date that can be used is 1970-01-01. The Unix epoch. Why that limit?<br><br>Gregorian calendar entered common use somewhere during the 15th century, I believe. Dates in 16th, 17th, 18th, 19th and 20th centuries are very common. Dates before the 15th centurie are less common, they are usually not precise (just 14th century, for example, as the exact year cannot be determined), but there are cases where the exact date is known. Julius Caesar is one instance where a precise date is known (for both his birth and death) and this is around 50 BC. I don't think there are many known precise date before that. I would accept that dates before year 1 be not represented. I would even accept that dates before 15th century be not representable since those cannot be accurately represented (I'm not historian, I hope people more knowleadgeable than me will point out the correct date for the event). However I think 1970 is not that good, as for sure even recent historic events cannot be pinpointed correctly.<br>
<br>If the protocol is to be kept as is, it should be made clear that the <time> element is for current dates, not historic dates, as I would assume that would be the reason for the choice of 1970 (which is actually a good choice for simplicity of implementation). If this was not the intended use (that is, it was also meant for historic dates) than the limit would really need to be changed. In my opinion, 1 or 1400 are not a good limit if we are to allow use for historic dates. I would allow all dates, including BC dates.<br>
<br>The upper limit does not seem to be mentioned. It should be, and it should be at least 9999, although no limit would be better (although I understand it becomes more difficult to implement past 9999 -- actually I think it's already diffucult to implement up to 9999).<br>
<br><br>