Time

[Graham Klyne]

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 
executions)
- 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.

#g


------------
Graham Klyne
For email:
http://www.ninebynine.org/#Contact