Re: Time

At 21:41 25/01/05 +0100, Ketil Malde wrote:

Graham Klyne 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