System.Time.Clock Design Issues
p.turner at computer.org
Thu Feb 3 11:32:13 EST 2005
The most recent messages motivated me to consider avoiding both POSIX and TAI
CalendarTime will provide a way to calculate date differences in whole days,
and to add n days to a date. This should account for leap years. Likewise
CalendarTime will provide a way to calculate time differences in seconds, and
to add/subtract n seconds. It would seem to follow that this should account
for leap seconds.
"Simon Marlow" <simonmar at microsoft.com> wrote:
> You can still do accurate calculations on calendar times in the future,
> and that's what matters.
However, the relationship between seconds and the future calendar is not
known. A specific second such as 2005-12-31T23:59:59 may turn out not to
occur. So even CalendarTime is not safe from leap seconds.
On 2005 February 03 Thursday 08:00, Ashley Yakeley wrote:
> During the leap second, the system clock is
> stepped, and getClockTime returns the wrong TAI time converted to the
> wrong (by up to a second) UTC time. After the leap second, getClockTime
> continues to return the wrong TAI time, but it is converted to the
> correct UTC time.
Until there's a system call that provides up-to-date information about leap
seconds, the above-quoted scenario can occur. Since future conversions
between calendar time and TAI are likely incorrect, how about raising an
exception? A TAI version of getClockTime would, in compiled code, go stale
and after a few months and start raising an exception. As a programmer, that
would steer me almost all the time to use a POSIX representation, and to do
CalendarTime difference calculations without accounting for leap seconds.
Here are my leanings on some of the points of discussion.
(1) POSIX time is useful primarily if you need to be close to the OS or to NTP
time. For general purposes I would avoid it unless I was sure I wanted to
calculate with seconds and didn't care about leap second inaccuracies.
(2) CalendarTime is the most useful form for applications. It should try to be
accurate in relation to leap seconds, but should not raise exceptions due to
e.g. (1) an incomplete leap second table or (2) reference to a second which
did not occur such as 2004-12-31T23:59:60.
(3) Some of the messages in this thread exhibit a tendency to reduce all times
and dates to a single representation, e.g. integral POSIX seconds + fraction.
That's a dead end. There's complexity in the conversions which means that a
program should make conversions sparingly and use a representation/calendar
that's close to the program's need.
(4) TAI is an important "calendar". It can specify future times that, for
scientific purposes, can't be matched by CalendarTime. The necessity for TAI
goes hand in hand with the impossibility of converting between future TAI
times and future calendar times. Nearly all programs made for home or
business do not need TAI. It is not properly supported by POSIX or Windows.
More information about the Libraries