Ashley Yakeley wrote:

* Can we assume that gettimeofday always returns UTC rather than TAI time?

POSIX says yes. People might set it differently, but there doesn't seem to be any way of detecting that.

I'd like to mention a technique that doesn't seem to have been suggested yet: we can probe the configuration of the user's system at run time by calling gmtime and friends with preselected arguments. In particular, the value of, say, gmtime(80000000)->tm_sec should suffice to distinguish between the following three cases: * time_t is TAI (atomic seconds since TAI epoch) and gmtime returns UTC (with leap seconds) * time_t is UTC (atomic seconds since UTC epoch) and gmtime returns UTC (with leap seconds) * gmtime is not leap-second aware In the third case I think it's sensible to assume that gmtime returns UTC +/- one second, since gmtime's output (modulo 15 minutes) is what the user will actually see, and if it's off by 20+ seconds, either they'll fix it, or they don't care what second it is and neither need we. From that we can derive an approximate TAI (and seconds-since-UTC-epoch) using an internal table of leap seconds. In the other two cases we can use one more gmtime call to test whether the system's leap-second table is at least as current as ours, and use either the system's or ours depending on that. I don't know if the first case actually occurs in the wild. The second case does occur on Linux systems which link /etc/localtime to something under /usr/share/zoneinfo/right/. Those people clearly care about accurate timekeeping and we should do what we can to cater to them. This site was helpful: http://www.thedjbway.org/clockspeed/leapsecs.html -- Ben

Ashley Yakeley wrote:

Time turns out to be complicated by nature, and it's not possible to be as simple as we'd like and still be completely correct: there's a trade-off between simplicity and correctness.

I lean towards correctness myself, I think there are ways of managing extra complexity. We might, for instance, be able to separate some of the less-used functions into another module fairly sensibly.

There's also a trade-off between simplicity and usefulness. My earlier message has one idea of where to draw the line, as well as one way of splitting the functionality: http://www.haskell.org//pipermail/libraries/2005-January/002930.html

Simon suggested naming the two modules "System.Time.Clock" and "System.Time.Calendar". These are the issues that seem to be remaining for the "Clock" module:

* Can we assume that gettimeofday always returns UTC rather than TAI time?

One question... get timeofday assumes things about the time-system. I would be happier with a 'gettime' call which returns some universal concept of time in an SI unit (which for time is seconds, so microseconds/picoseconds whatever) I am uncomfortable with introducing non SI notions of time interval like hours/minutes (even days) as these may vary... I feel conversion into 'familiar; units should be done from this universal time... Especially if anyone wants to write software for the Mars mission! Keean.