System.Time.Clock Design Issues

[Scott Turner]

The most recent messages motivated me to consider avoiding both POSIX and TAI 
time.

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.