Wed, 18 Jun 2003 11:20:29 +0100
> yup. unfortunatly this brokenness is mandated by POSIX:
Here's a link to the definition in the latest POSIX standard:
(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
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
> 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