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? POSIX says yes. People might set it differently, but there doesn't seem to be any way of detecting that. We can't used time-zone setting AFAIK, because gettimeofday is supposed to be universal time independent of time-zone. My preference is to assume people are following the POSIX standard, since that's the assumption that most software makes (including NTP I believe). * Should there be a TAI type separate from a POSIX time type that the system clock would return? My preference is yes. If necessary we could create a third module for TAI time and explicit leap-second handling, which will keep them out of the way for most people. Separate types is more complication, but the alternatives have their own issues: http://www.haskell.org//pipermail/libraries/2005-February/003049.html * What resolution should we use, and should it be platform-dependent? My preference is (platform-independent) picoseconds to match the existing System.Time library and as a hedge against Moore's law. * Should we include a (days,ticks) UTC type separate from the POSIX time type? I have two reasons for wanting this. Firstly, correctness: the POSIX time type cannot represent leap seconds, whereas this can. Secondly, this holds the result of a useful function that splits POSIX time into the simplest possible date and time parts, which can then be used for converting to various internationalised calendars. -- Ashley Yakeley, Seattle WA