If you’re interested in this stuff at all, you’ll probably know this, but for the sake of completeness, the <time> element has returned to HTML5 after it was removed from the specification.
I reserved cheering until in case it was grudgingly returned to the W3C spec but not the WHATWG spec, as I don’t particularly want to see forked specs.
The old version of the element is now in the W3C spec, but not in the WHATWG version. But I’m not worried; it appears that it will be added as a New!Improved! element with some extra features to make it actually useful that I’ve been asking for since March 2009.
Editor Ian Hickson wrote
A few weeks ago, I replaced <time> with <data>. We got feedback from many people saying that there were use cases that <data> didn’t handle, and requesting <time> be left in the spec. It turns out what people were asking for was not quite the old <time> element, it was more like a variant of <data> that was specifically for <time>. (The old <time> was specified as doing locale-specific rendering, had a more or less useless API, and only supported a small set of data and time syntaxes.) Tantek made a proposal for how to handle these use cases, which I intend to add to the spec ("the <time> element is dead, long live the <time> element").
Indeed. <time>2.0. Time, after time.
Hickson has also hinted that we might get a <geo> element, too (as I suggested in my HTML5 Semantics talk at Fronteers.)
(Let’s just hope Tantek doesn’t neglect the vital use-case of 4 simultaneous days in 24 hrs advocated by Gene Ray’s Timecube theory.)
Buy "Calling For The Moon", my debut album of songs I wrote while living in Thailand, India, Turkey. (Only £2, on Bandcamp.)