[whatwg] Time element, atribute, kind of second

Gerard Ashton ashtongj at comcast.net
Sun Oct 26 14:52:04 PDT 2008

I note that the time element has four attributes.

The three attributes of type DOMTimeStamp (the date, time, and timezone
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
cannot be described. While the datetime string is allowed to have year
such as 0057, such a value cannot be represented by the date attribute.

Furthermore, the only words in the specification that would imply a
length for the second (and therefore the millisecond) are UTC or Coordinated
Universal Time. Since 1972 UTC has counted in the second of the
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
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
attributes and converting to a character string representation of the time
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
The problem of the date attribute failing for some information about living
would suggest choosing an epoch before an living person was born, such as
adoption of the Gregorian Calendar (1582-10-15). If a date near 1970 really
seen as a desirable date, 1973-01-01 00:00 UTC suggests itself, because the
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
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
itself is to say that the epoch is 1973-01-01 00:00 UT1, not UTC, and that
times represented are UT1 times, not UTC. Thus the unit of measure for the
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
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
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


More information about the whatwg mailing list