I note that the time element has four attributes. The three attributes of type DOMTimeStamp (the date, time, and timezone attributes) seem the most troublesome, for the following reasons.
Since DOMTimeStamp is an unsigned long integer, and 0 ms represents 1970-01-01 00:00 UTC, (the proposed HTML 5 epoch) many events about living people cannot be described. While the datetime string is allowed to have year values such as 0057, such a value cannot be represented by the date attribute. Furthermore, the only words in the specification that would imply a particular length for the second (and therefore the millisecond) are UTC or Coordinated Universal Time. Since 1972 UTC has counted in the second of the International System of Units, that is, the second of atomic clocks. The actual mean solar second is slightly longer. From the time of the proposed HTML 5 epoch until January 1, 2009, atomic time and UTC diverge by 29.7683 seconds. This accounts for the leap second that occurs at the end of 2008. The next leap second after that will cause the difference between HTML 5 time and UTC to be more than 30 seconds, which means that if rounded to the nearest minute, the minute value will differ by 1. This means that the simple process of converting adding the date, time, and timezone attributes and converting to a character string representation of the time (rounded to the nearest minute) can result in a different minute value relative to what what a clock on the wall would show. The choice of epoch matches the epoch for Unix, but otherwise seems inconvenient. The problem of the date attribute failing for some information about living people would suggest choosing an epoch before an living person was born, such as the adoption of the Gregorian Calendar (1582-10-15). If a date near 1970 really is seen as a desirable date, 1973-01-01 00:00 UTC suggests itself, because the use of leap seconds began 1973-01-01 00:00 UTC, so any algorithm that needed to account for the difference between atomic time and UTC would only have to deal with integer differences (even if the algorithm needs to work with values slightly before the epoch). Considering the inability to represent leap seconds in the time element, it appears to me the only way to write a specification that does not contradict itself is to say that the epoch is 1973-01-01 00:00 UT1, not UTC, and that the times represented are UT1 times, not UTC. Thus the unit of measure for the attributes would be seconds of mean solar time as measured by UT1, not seconds as kept by atomic clocks. Since UT1 does not observe leap seconds, the limitation of the time element will not cause outright errors and contradictions. The absolute value of the difference between UTC and UT1, which is always less than 0.9 second, seems unlikely to cause trouble for the types of applications envisioned for this element. For further information on the difference between UTC and atomic time (TAI) see http://maia.usno.navy.mil/ser7/tai-utc.dat Gerry