Concerning Time.TimeDiff

[Simon Marlow]

> yup. unfortunatly this brokenness is mandated by POSIX:

Here's a link to the definition in the latest POSIX standard:

http://www.opengroup.org/onlinepubs/007904975/basedefs/xbd_chap04.html#tag_04_14

(I don't know if they fixed the leap year "typo" or not).

Regarding the TAI vs. UTC debate:  my intention was that ClockTime should be an absolute interval of elapsed time since a
well-defined point in time.  Unix time_t clearly doesn't measure up, because as already pointed out by John and others, it ignores
leap seconds.  

John suggested using (pico)seconds since 1970-01-01 00:00:10 TAI.  Isn't this equivalent to saying that ClockTime is the number of
seconds since 1970-01-01 00:00:00 UTC?  Either way, I think we're in agreement that ClockTime should not use the POSIX notion of
"seconds since the epoch", but instead use an absolute measure of time interval.

I've attached the revised proposal below.  Changes so far:

  - ClockTime and TimeDiff are now represented as 
    Integer picoseconds only.  Hence, they also now derive
    Num, Enum, and Integral.

  - ClockTime is defined as picoseconds since the epoch, where
    the epoch is defined in terms of TAI.

  - calendarTimeToClockTime now returns a Maybe.

  - I've commented out addDays and friends.  I assume that
    there isn't an immediate demand for these functions, so
    they can be left out until later, or moved to a separate
    library.

> the only source of confusion I can think of is if the Integer
> representing TAI relative to epoch is misinterpreted as a time_t
> equivalent under POSIX, providing toPosixUTC :: ClockTime -> Integer
> and fromPosixUTC :: Integer -> ClockTime would be useful and advisable

These should be provided by System.Posix.Time, I think.

   clockTimeToEpochTime :: ClockTime -> EpochTime
   epochTimeToClockTime :: EpochTime -> ClockTime

Cheers,
	Simon