[LEAPSECS] Java: ThreeTen/JSR-310

[Stephen Colebourne]

On 28 January 2011 20:42, Tom Van Baak <tvb at leapsecond.com> wrote:

> 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.


JSR-310 is designed to use nanoseconds pretty much throughout. This is
primarily because some databases store nanoseconds. Clearly, an
accurate clock at that resolution is unlikely ATM.

The TimeSource interface allows the clock implementor (not me) to
provide either a TAI, UTC or standard (86400) instant. The current
implementation uses the current Java millisecond value without leap
seconds. I hope that others will implement a better mapping for their
operating system (another thread mentions FreeBSD has good support).

As you say, the pretence of accuracy at that level is crazy for most
users. But over time, I suspect that greater accuracy will be
obtained, and the API is designed to allow that, while maintaining
86400 second days and the continual forward motion of time given a
good clock.

Stephen