http://www.whatwg.org/specs/web-apps/current-work/multipage/common-microsyntaxes.html#parse-a-month-component
Is there a use case for machine-readable dates after 9999? I'm sure HTML5
will have been obsoleted before it's meaningful to express accurate times
that far in the future. As existing similar formats use a 4-digit year,
adapting parsers for those is a lot easier if the HTML5 year format be
exactly 4 figures. Also, it seems more likely that >4-digit years will be
typos than intended and useful as machine-readable data. If there are no
strong use cases for it, please make it YYYY only.
http://www.whatwg.org/specs/web-apps/current-work/multipage/common-microsyntaxes.html#parse-a-date-or-time-string
"10. If the date present and time present flags are both true, but
position is beyond the end of input, then fail."
This seems to be a bug if you consider how '2009-11-16T' would be parsed.
The algorithm is supposed to return a date time or global date and time,
but '2009-11-16T' is valid as neither. The intent of this step must be to
make sure that T is always followed by a date, but it won't work. Except
from being in the incorrect order (after time present may have been set to
false) it also checks for the end of input, which doesn't make sense when
the "in content" variant is used.
Perhaps it would be possible to simply replace this algorithm with "try
parsing a global date and time, else try parsing a date, else try parsing
a time"? I haven't check carefully if this is equivalent though.
http://www.whatwg.org/specs/web-apps/current-work/multipage/rendering.html#the-time-element-0
"When the time binding applies to a time element, the element is expected
to render as if it contained text conveying the date (if known), time (if
known), and time-zone offset (if known) represented by the element, in the
fashion most convenient for the user."
This is very vague. Anything which tries to localize the date/time will
fail because guessing the language of web pages is hard. Hard-coding it to
English also wouldn't be very nice. What seems to make the most sense is
using the "best representation of the global date and time string" and
equivalents for just time and date that have to be defined. Still, I'm not
sure this is very useful, as the same rendering (but slightly more
flexible) could be accomplished by simply putting the date/time in the
content instead of in the attribute. As a bonus, that would degrade
gracefully. Unless I'm missing something, I suggest dropping the special
rendering requirements for <time> completely.
--
Philip Jägenstedt
Opera Software
