System.Time.Clock Design Issues

[Ashley Yakeley]

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

> I don't think we should have a type for POSIX time.  What does it buy
> you?  POSIX time is a broken notion that shouldn't be visible in our
> library interface.

> Suppose we just have a TAI time type, plus various calendar types.  What
> goes wrong?  Well, you can't accurately convert some TAI times into
> calendar times and vice versa, in particular all times more than 6
> months ahead of the leap second table.  Too bad.  You can still do
> accurate calculations on calendar times in the future, and that's what
> matters.

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?

-- 
Ashley Yakeley, Seattle WA