Seth Kurtzberg
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