System.Time.Clock Design Issues

[Ashley Yakeley]

In article 
<3429668D0E777A499EE74A7952C382D1031907F4 at EUR-MSG-01.europe.corp.microso
ft.com>,
 "Simon Marlow" <simonmar at microsoft.com> wrote:

> On 03 February 2005 10:44, Ashley Yakeley wrote:
> 
> > OK, so we have
> > 
> > * POSIX time
> > 
> > Can do accurate calculations on calendar times.
> > Can store UTC times reliably.
> > Cannot store TAI times reliably.
> > Broken for all leap seconds.
> > 
> > * TAI time with limited leap-second table
> > 
> > Can do accurate calculations on calendar times.
> > Cannot store UTC times reliably.
> > Can store TAI times reliably.
> > Broken for leap seconds after table runs out.
> > 
> > Which of these is better?
> 
> The point is that everything you can do with a POSIX time you can also
> do with a calendar time, which we need anyway.  So why have a POSIX time
> too?

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


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

Getting rid of it all and using CalendarTime means slower clock 
retrieval and calculations as well as time-zone uncertainty.

What would you recommend?

-- 
Ashley Yakeley, Seattle WA