System.Time.Clock Design Issues
ashley at semantic.org
Thu Feb 3 08:00:32 EST 2005
On Feb 3, 2005, at 04:09, Simon Marlow wrote:
> That's a good way to put it.
> I think TAI + calendar time covers all the bases, except that you can't
> do *really fast* second-based calculations that ignore leap seconds.
> But (a) I don't think this is something we should encourage and (b) I
> don't think we should expose an inherently wrong representation of time
> (i.e. POSIX).
It's true that POSIX is an inherently wrong representation of UTC, as
it is wrong at leap seconds. The trouble is, what you are suggesting is
a type that is wrong in a much more complicated way: it starts off as a
correct representation of TAI, and turns into a representation of UTC
that is also wrong at leap seconds.
Let us suppose we have a system clock that keeps POSIX time, and a
Haskell function, getClockTime, that returns the current ClockTime you
are suggesting. I compile a program that calls this function.
At first getClockTime returns the correct TAI time, which can be
converted into the correct UTC time. Then, in two years' time, a leap
second is announced. During the leap second, the system clock is
stepped, and getClockTime returns the wrong TAI time converted to the
wrong (by up to a second) UTC time. After the leap second, getClockTime
continues to return the wrong TAI time, but it is converted to the
correct UTC time.
What we end up with is a type that no longer represents TAI. Instead,
it represents a fixed offset to UTC. The only way to get anything
correct out of it is to convert it to UTC, though even then, it won't
be correct during a leap second -- exactly like POSIX time.
It's the same if we wish to measure time offsets. Supposing I want to
know how long something takes, of the order of seconds. I call
getClockTime at the beginning and end of the interval, and subtract one
from the other. This will be correct most of the time, but if there was
a leap second in between, which the library cannot predict if my
program was compiled years ago, then the calculation will be off by a
second. Again, this is exactly like POSIX time.
So what we have is a type that behaves like TAI for the past, but POSIX
time for the future, even though it's supposed to be TAI. Surely it
would be better to simply use POSIX time?
Ashley Yakeley, Seattle WA
More information about the Libraries