On 11 February 2005 01:54, Seth Kurtzberg wrote:
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.
I don't see why you claim the library will produce incorrect answers. It will produce answers exactly as correct as the OS interfaces on which it is based. If you want to do accurate interval calculations then you have to use TAI, and if you need to convert between TAI and UTC then you also need appropriate leap second tables to hand. The library allows you to do this, and the documentation for the library will explain exactly why you have to use TAI if you need to do this. So what's the problem? Cheers, Simon