Indeed a very enlightening discussion. Everybody knows this stuff is complicated but the author does a stellar job in pointing out just how ridiculously convoluted it really is.
Having a powerful <time> element as the author suggests would definitely be amazingly useful. Not only for historians but also for us mere mortals. For example, many web-developers could benefit greatly from being able to perform simple date arithmetics in markup. All those little time-related tidbits such as "posted 3 hours ago" or "due in 2 days" have to be computed somewhere and being able to do that in straight markup instead of the current server-side or javascript approaches would be an advantage. At the very least it could do away with many of the timezone and "browser time vs server time" related headaches that we deal with today.
Anyways due to the massive complexity this would very well deserve to be spun off into a separate project maintained by specialists, akin to MathML.
But given the track-record of the W3C I fear neither will happen. Instead we'll get the usual half-baked solution after the usual 5-10 year snail-race.
And then, ofcourse, MSIE will come along and establish a broken parallel universe...
This guy has some interesting and worthwhile things to say. However, his whole discussion seems to be predicated on the idea that, if the specs for the <time> element were changed appropriately, then everyone would follow the official standard.
A 10-second look at the web tells us this is not going to happen.
So, suppose some document is written indicating how the <time> element works. What reliable guarantees does that give us concerning the use of the <time> element on real web pages? Answer: None.
So, nice try, and an interesting article, but I really do not think it's going to work.
HTML 5 is two things: a codification of how browsers parse documents and handle errors, and a slew of new features for HTML and JavaScript.
The first part is more of a set of guarantees that browser vendors can agree upon, and I believe it's largely based on IE's behavior.
The new features are already slowly trickling into browsers. For example, Firefox, Opera, and Safari all implement <canvas>. There are a number of other features that are already implemented in browsers, which you can read about here: http://wiki.whatwg.org/wiki/Implementations_in_Web_browsers.
So, right now some new features are closer to the mainstream than others, especially where there are 3rd party implementations for IE (like ExplorerCanvas, and Google Gears which will probably have HTML5 APIs at some point). I wouldn't hesitate to play around with these new technologies, especially at the rate they're being implemented.
Having a powerful <time> element as the author suggests would definitely be amazingly useful. Not only for historians but also for us mere mortals. For example, many web-developers could benefit greatly from being able to perform simple date arithmetics in markup. All those little time-related tidbits such as "posted 3 hours ago" or "due in 2 days" have to be computed somewhere and being able to do that in straight markup instead of the current server-side or javascript approaches would be an advantage. At the very least it could do away with many of the timezone and "browser time vs server time" related headaches that we deal with today.
Anyways due to the massive complexity this would very well deserve to be spun off into a separate project maintained by specialists, akin to MathML.
But given the track-record of the W3C I fear neither will happen. Instead we'll get the usual half-baked solution after the usual 5-10 year snail-race. And then, ofcourse, MSIE will come along and establish a broken parallel universe...