System.Time.Clock Design Issues

[Ashley Yakeley]

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