gk at ninebynine.org
Wed Jan 26 05:32:13 EST 2005
At 21:41 25/01/05 +0100, Ketil Malde wrote:
>Graham Klyne <GK at ninebynine.org> writes:
> > At 08:56 25/01/05 +0100, Ketil Malde wrote:
> >> I think we all agree on having Time as an Integer or similar
> >> representing time with some particular resolution. The question seems
> >> to be how to deal with CalendarTime, defined as a record with fields
> >> for the various components found in a human-type time stamp.
> > Just for the record, my silence is not consent on this.
> > [..] (days,ticks)
>This (almost) falls in under "similar". Unless you feel this model
>subsumes the "calendar" type of time, in which case I'd like to see
>the reference as well.
If (days,ticks) counts as similar, then I agree that I'm not a
counterexample to your original assertion.
Turning to the more general discussion of time... how complex a time
library do we want? What sorts of things do folks actually want to do with
time values most of the time? I think (intuitively, without hard evidence)
that a simple library can handle many of the requirements, such as:
- accurately representing duration of "short" processes (e.g. program
- approximately representing duration of longer processes
- representing the date/time of human-scale events
I regard timezones (as opposed to timezone offsets from UTC) and leap
seconds as specialized issues that don't impact many of the common uses for
date/time. A time library shouldn't preclude sensible implementations of
these, but I don't think it needs to include them all.
In summary, I suggest: keep it simple.
More information about the Libraries