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

[Tom Van Baak]

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


Stephen,

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?

That way your millions of users get what they want, they don't
have to know the implementation, in fact they cannot know the
implementation. The whole point is to hide the implementation.

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 ;-) Or you could go one step further and create an API
that allows the user to specify their own smoothing parameters,
within reason. No, skip that.

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.

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.

Your class can stay above these issues. Leave the name SLS
out of it. Just provide a generic 24x60x60 almost-UTC time
scale (UTC60?); that's all your users need. No code needs to
change and no API names need to change if UTC evolves in
the coming future.

Let the class name convey a service to the users, something
positive; not convey a problem (leap seconds) or a problem
solved (smoothed leap seconds) or a specific implementation
of the solution to the problem (UTC-SLS). Isn't this level of
insulation or abstraction part of the reason one creates these
uber time classes in the first place?

/tvb