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_0... (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