System.Time.Clock Design Issues

[Simon Marlow]

On 03 February 2005 02:54, Ashley Yakeley wrote:

> * Should there be a TAI type separate from a POSIX time type that the
> system clock would return?
> 
> My preference is yes. If necessary we could create a third module for
> TAI time and explicit leap-second handling, which will keep them out
> of the way for most people. Separate types is more complication, but
> the alternatives have their own issues:
>
<http://www.haskell.org//pipermail/libraries/2005-February/003049.html>

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.

The most common conversion between TAI & calendar time is going to be
for the current time, and that will be correct as long as we have an up
to date leap second table.  Even if we don't have an up to date leap
second table, we can still convert from system clock-->TAI-->calendar
time, because the leap second calculations cancel out (for a POSIX
system clock).

> * Should we include a (days,ticks) UTC type separate from the POSIX
> time type?
> 
> I have two reasons for wanting this. Firstly, correctness: the POSIX
> time type cannot represent leap seconds, whereas this can. Secondly,
> this holds the result of a useful function that splits POSIX time into
> the simplest possible date and time parts, which can then be used for
> converting to various internationalised calendars.

I don't think we need this either, at lesat not in the external
interface.  Any calculations you can do with this type you can do on a
calendar time.

Cheers,
	Simon