System.Time.Clock Design Issues

[Aaron Denney]

On 2005-02-03, Ashley Yakeley <ashley at semantic.org> wrote:
>> 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.

Yes, it is.  Monotonic consistently scaled time is far more important
than future conversions to UTC.  If someone needs time precision
down to the second for a time over six months in the future, they
need to specify whether they want N seconds from now (use TAI) or
a specific calendar time (in which case they should store that calendar
time.

> People need UTC time much more than they need TAI time, though TAI
> time is of course correct for intervals.

They need TAI clocks more than UTC clocks, but UTC calendars, as there
is no TAI calendar.  We have a clock with simple and nice properties,
and a calendar with annoying properties to keep it in sync with Earth.

> The simplest possible representation of UTC if you don't 
> mind being wrong at leap seconds is something like POSIX time.

IOW, fundamentally incorrect.

> The simplest possible correct representation of UTC is either a       
> (days,ticks) struct, which is slightly more complicated for the       
> kernel,

True, but the _kernel_ needn't know about the calendar, even to obey
POSIX.  All the conversions can be done in the userspace bindings to the
system call.

-- 
Aaron Denney
-><-