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"
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.