As I said before, having looked at the subject, I now strongly believe that any alteration to the current scheme of occasional leap-seconds would be a serious mistake with large consequences.
Stephen, Two questions. Can you explain the above comment a little more? I ask because one of the key reasons for the proposal to eliminate leap seconds is to address the very intractable issue that you and all the other API and military/commercial system implementers before you have faced. Hopefully no one will jump on you but it would be useful for you to describe the evolution of your strong beliefs. Second question -- I assume your design of the new java class needs to address two different audiences; one are the 8 million developers but the other are the several dozen (?) implementers of the class on their own particular host OS or hardware, yes? The question is what specification of accuracy is there for any of these APIs? I understand of course that when you use units like nanoseconds you don't mean accuracy. But when users or implementers see words like TAI and UTC there is often some level of assumption of second or sub-second accuracy. Do you address this issue at all? As a guarantee to the user? Or perhaps as a requirement of the implementers? I partly ask because for the class of users who are willing to be close enough to UTC (say within 1 second), there are no leap second issues, ever. This covers most users on the planet. We know their PC's, laptops, phones, watches, and email say "UTC", but it's really just an 86400 clock that's close enough to UTC. This flexibility means they are perfectly happy with non-leap API's. There is no need for smoothing -- under the API's there already is enough jitter, wander, smoothing, NTP, clock setting and resetting. In all these cases there is no need for an additional layer of micro-step or milli-step smoothing. The user has no requirement of sub-second precision and the APIs meet that expectation. /tvb _______________________________________________ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs