Time library

[John Meacham]

On Thu, Jul 31, 2003 at 12:42:00PM +0100, Simon Marlow wrote:
> When we last left the discussion, the conclusion was that having a
> ClockTime defined in terms of TAI was not implementable, because we
> can't tell whether the system clock is running POSIX time_t or a variant
> that is correct and includes leap seconds.  (please correct me if I'm
> wrong).
ack! I don't remember concluding this, this would break many of the
advantages of our new time library. The whole point of making ClockTime
an integral is that simple math works on it. this is possible ONLY if it
is specified in terms of TAI. both posix time and UTC cannot be
subtracted, added, or represent times before 1970ish.

We should define the ClockTime to be in terms of TAI to the best of the
systems ability. at worst, we subtract 20 seconds from posix time, this
would be infinitly better than not knowing whether ClockTimes are TAI or
posix and whether we can safely subtract them or do anything interesting
with them. 

> If the system clock is running POSIX time_t, then it is possible to
> determine the correct TAI time, given a table of leap seconds.  There
> was some feeling that it shouldn't be our responsibility to do this,
> that the system should provide us with correct time in the first place.
> I'm inclined to agree (it's less work for those of us who have to
> implement this stuff after all :-).
the table is needed anyway to accuratly represent  time durations and to
do CalendarTime conversions specified. our job is not any easier by
letting ClockTime be undefined, we just loose functionality. as long as
the haskell implementation is self-consistent, it does not matter too
much what we use as our leap second table.  

> So, given this, I've updated the proposal to include everything
> discussed so far and to note the fact that having a correct ClockTime is
> at the mercy of the system.

We should specify the ACCURACY of ClockTime is at the mercy
of the system, but the expected scale and meaning should be well
defined. let's not trade our current crippled time library for one that
is just broken in it's other leg. all this does is shift where the
problems are.

so my proposed changes:

specify ClockTimes are in terms of TAI to the systems best ability.

(posix time_t is not the systems best ability. posix and tai have
diverged quite a bit, if we know we have posix, then a fixed offset from
it gives an acceptable innacurate TAI time, a hardcoded 20 or so entry
table gives an exact one for all past times, and one which uses libtai
or similar system resources (when available) to consult an oracle give
perfect results always)

add 
toPosixTime :: ClockTime -> Integer
fromPosixTime :: Integer -> ClockTime 
as convienence routines. so users don't have to go through an
intermediate CalanderTime. 

we also might want to allow rfc2822 style timezones. of the form "+nnnn"
where nnnn is the offset from GMT. convienince routines to convert
to/from rfc2822 time strings might be handy too. this is all not as
important as it could be done in an add-in library, but might get common
usage.

we also might want to add routines to consult the leap second oracle
(which might be as simple as returning a single hardcoded value) since
it could come in handy for a haskell program to know exactly how the
internal times routines are working. 

        John

-- 
---------------------------------------------------------------------------
John Meacham - California Institute of Technology, Alum. - john@foo.net
---------------------------------------------------------------------------