Aaron Denney wrote:

On 2005-02-10, Scott Turner <p.turner@computer.org> wrote:

On 2005 February 10 Thursday 07:19, Simon Marlow wrote:

On 10 February 2005 12:12, Marcin 'Qrczak' Kowalczyk wrote:

And the simple fact that obtaining TAI from systems in use requires
periodic updates of the leap second table causes other difficulties.

This is a vitally important bit of rationale which has emerged from the
current discussion.  I certainly didn't fully appreciate the
difficulties with basing the library on TAI before,

Another significant bit for me was the realization that TAI is no good for 
scheduling future events on an everyday calendar. If I schedule a new year's 
celebration for Jan 1, 2006, that would be represented in TAI as 1514764832.0 
seconds after the epoch. If a leap second is inserted at the end of 2005, 
then my celebration at 1514764832.0 TAI will be premature. Even if we go to 
the trouble of keeping our leap second tables current, this is still a 
problem.


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

We are getting bogged down in the terminology here. My problem is that, as proposed, the library will give wrong answers. Having a nanosecond granularity library that can't even manage one second accuracy doesn't seem useful to me. Apparently, though, I'm in the minority here, so I'll let it go.

The comment about scheduling is not correct, because the leap year correction is always available. To me, it is more important to get the correct answer when, say, finding the amount of time that has passed from one timestamp to another. I can't see the logic in a library that returns incorrect answers, because to return correct answers is more difficult.

I guess those people who intend to use it don't care if the interval results are correct. I do care, but I'll have to implement it myself since I appear to be a minority of one.