System.Time.Clock Design Issues

[Simon Marlow]

On 03 February 2005 11:30, Ashley Yakeley wrote:

> Sure, we could get rid of it entirely and rely on CalendarTime
> everywhere. This is the trade-off I see:
> 
> * POSIX time
> 
> not already necessary
> fast retrieval from system clock
> fast calculation of time differences and offsets
> independent of time-zone
> 
> * Structured calendar time
> 
> already necessary anyway
> slow retrieval from system clock
> slow calculation of time differences and offsets
> may be dependent on time zone

The time zone issue is a red herring.  You can use UTC calendar time
exclusively if you want.

I disagree that calendar time has slow calculation of time differences
and offsets:

  - for time differences measured in units of minutes and larger,
    the broken down calendar time is easier to do calculations on.

  - for units smaller than a minute, doing calculations with either
    of them might give wrong results.  You need to use TAI time instead.

I think you're suggesting that we allow calculations in units of seconds
on POSIX time and calendar time, and just document that they don't take
into account leap seconds.

I'd rather say that you can do accurate calcuations on TAI time, but
conversions might be wrong.  Second-based calcuation on calendar time
can be done by converting to TAI to do the calculation.  You can also do
second-based calculations ignoring leap seconds on a calendar time if
you want.

> In summary:
> 
> Using TAI with a limited leap-second table is trading a simple kind of
> brokenness (all leap seconds) for a complicated kind (future leap
> seconds after some date).

That's a good way to put it.  

I think TAI + calendar time covers all the bases, except that you can't
do *really fast* second-based calculations that ignore leap seconds.
But (a) I don't think this is something we should encourage and (b) I
don't think we should expose an inherently wrong representation of time
(i.e. POSIX).

For people who want to measure time differences between two points, the
library API should encourage them to use units of minutes and larger,
which are independent of leap seconds.

Cheers,
	Simon