[whatwg] Time element, atribute, kind of second

[Gerard Ashton]

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