System.Time.Clock Design Issues
ashley at semantic.org
Wed Feb 2 21:53:45 EST 2005
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:
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
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
My preference is to assume people are following the POSIX standard,
since that's the assumption that most software makes (including NTP I
* 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:
* 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
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
More information about the Libraries