[LEAPSECS] Java: ThreeTen/JSR-310

[Tom Van Baak]

> 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