System.Time.Clock Design Issues

[Ashley Yakeley]

> But I agree with the rest of what you say.  Basically, providing TAI
> time is problematic because we can't implement it correctly, for future
> times, on systems that only provide POSIX time.

Yes. Any solution that involves compiling in a leap-second table is 
going to run into trouble when the table becomes out of date.

> At this point I'm not sure what is best, I'm still quite disturbed by
> the idea of basing the definition of the Haskell Time library on what 
> is
> basically a mistake in the definition of POSIX :-)

It's not clear what POSIX should have done. People need UTC time much 
more than they need TAI time, though TAI time is of course correct for 
intervals. The simplest possible representation of UTC if you don't 
mind being wrong at leap seconds is something like POSIX time. The 
simplest possible correct representation of UTC is either a 
(days,ticks) struct, which is slightly more complicated for the kernel, 
or something that's days*86401+seconds, i.e. with a gap for a leap 
second every day, which is a nightmare for time differences.

-- 
Ashley Yakeley, Seattle WA