Time Libraries Rough Draft

[Ketil Malde]

Seth Kurtzberg <seth at cql.com> writes:

>> Yes, because TAI is a clock, not a calendar.

> We are getting bogged down in the terminology here.  

I've tried -- but am happy to try again -- to propose:

     clock : something that measures the passage of time,
             unit is seconds

     calendar: something that deals with the passage of time
               with other units -- hours, minutes, years, dates

I guess one reason this is not a simple and useful distinction is that
people prefer POSIX' time, where the second count is computable from
the UTC calendar alone (and vice versa), and thus a POSIX "second"
(a "psecond"?) is sometimes two SI seconds, and sometimes none.

I think it is desirable that a clock has good accuracy, while it is
less of a problem if a calendar is wrong -- new year celebrations
nonwithstanding. 

> My problem is that, as proposed, the library will give wrong answers.

The problem is wanting a one-to-one correspondence between the
clock (counting seconds) and the calendar (describing other time
entities, like hours or dates).

POSIX is AFAIK the only way to handle this, and it is done by changing
the definition of "second".  A POSIX clock (unlike an SI-seconds based
one) will of course only be able to keep time correctly or calculate
correct durations (as SI seconds) if has access to leap second
tables.  

The advantage of POSIX is that you don't need the leap second table to
calculate the UTC calendrical presentation of time.  Well, most of the
time, anyway -- it won't work *during* a leap second, I guess.

If you store the time to new year as SI seconds, you will have the
problem of leap seconds, even if you use UTC -- you will need to know
whether 2005-12-31T23:59:60 exists or not.  (Or you can go the .NET
route, which just pretends it is an error.)

And of course, accurate time depends on distributing leap second
tables anyway, as you need to know when to slow down the POSIX clock. 

> Having a nanosecond granularity library that can't even manage one
> second accuracy doesn't seem useful to me.

We would be in good company.  With all the legacy baggage, it is
rather utopian to expect computers to be able to deal sensibly with
leap seconds for the foreseeable future.

> I can't see the logic in a library that returns incorrect answers,
> because to return correct answers is more difficult.

Accurate timekeeping really isn't that important for computers.

-kzm
-- 
If I haven't seen further, it is by standing in the footprints of giants