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.
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 :-).
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. 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 ---------------------------------------------------------------------------