[LEAPSECS] Instant (86400 second Java class) [was Java: ThreeTen/JSR-310]

[Stephen Colebourne]

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

>>> Your java class going to provide the true TAI, the true UTC,

>>> and the a user-friendly (smoothed, non leap second) version

>>> of UTC, right? If so, what name do you plan to use for that

>>> latter time scale? Some OS's use words like "system time"

>>> or "gmtime".

>>

>> I call it the "UTC-SLS" time-scale. See new thread on Instant.

>

> Would it be possible to expose to the user a UTC-like class

> that is guaranteed to be within 1 second of true UTC and is

> guaranteed to have 86400 seconds a day (no leap seconds)

> but leave the implementation details to the guys who write the

> class?


JSR-310 is both a spec and an implementation (well ThreeTen is
strictly speaking the implementation, but thats a detail). I do not
expect anyone else to implement the spec in *Java* code. However, you
are correct that the spec will be implemented by multiple independent
people to implement the associated clock (probably in C), and they may
be limited in terms of what they have access to.

Lets say we define a new time scale FDS which is the
fixed-day-subdivisions scale where days always have 86400 subdivisions
(commonly known as seconds) but there is no fixed mapping to TAI of SI
seconds other than a restriction that the length of an FDS day must
not be more than 0.9 SI seconds from the mean solar day.

Well, thats fine as a few words, but its very wishy washy in practice.
If one implementation uses smoothing over the whole day, and another
uses UTC-SLS (both valid implementations of the FDS spec), what
happens when those two implementations communicate? A timestamp may be
out. Now while that may happen anyway, making it more likely doesn't
seem like moving the world forwards. (And I doubt FDS would achieve
consensus as a definition on this list or standards bodies)

Choosing UTC-SLS as the only approach is dictatorial, but lays down a
marker to others. It puts pressure on OS writers to provide accurate
UTC or UTC-SLS, which seems to me to be a good thing.



> Given that, the various ports of this class can adapt to whatever

> hardware or OS using the smoothing algorithm of their choice;

> one that fits. Under the hood it could be the double long 59

> method or the double 00 method (both a form of SLS(1)), or

> SLS(60), or SLS(1000), or SLS(86400). Further Michael can

> use UT1 for his implementation of the class, and still meet the

> spec ;-)


Sounds nice, but I think that way leads to more confusion, not less.

I could define as "an 86400 subdivision day where any UTC leap second
must be resolved to subdivisions by smoothing covering a period
starting no earlier than 23:00 and finishing at midnight where a
smoothing factor of 1000 seconds is preferred". That definition gives
implementors some flexibility while avoiding complete separation of
implementation strategies. But I'm not sure its really a helpful
direction to go.


> But if you're trying to make an easy time class for millions of

> people to use, 86400 is the kind of number they want to see

> in the class description. Not worrisome times like 23:43:21.


In that I agree. I might move the whole UTC-SLS section just to the
UTCInstant class, with simply a reference from Instant. Most users
don't want to see such a complicated explanation, as they might think
they need to understand it!


> One problem with the UTC-SLS draft proposal is that is stands

> only as a reaction to UTC, as UTC is currently defined. If/when

> leap seconds go away the entire premise of UTC-SLS and its

> hardcoded milli-leaps vanishes, leaving it an awkward, though

> creative, nop of history.


True. But I'd still need some way to describe time between 1972 and
the mythical date when leap seconds stop. And I'd still need a
smoothing for that. (As I've said before, stopping leap seconds now
isn't helpful as it adds yet another mapping/complication, rather than
removing one)

Nevertheless, this is an intriguing approach to the class.

Stephen