[LEAPSECS] Lets get REAL about time.

[Stephen Colebourne]

On 20 January 2012 16:31, Poul-Henning Kamp <phk at phk.freebsd.dk> wrote:

> >There is an IEEE spec for a large decimal number, which would be

> >preferable. Or a 96/128 bit integer.

>

> Only, it is not implemented anywhere, binary128 is.


Fine, but I'm very unenthused about floating point numbers in general.
I'm not sure you've made your case for not using a 128 bit integer,
defined as (say) attoseconds.


> >When designing the Java API, I concluded that it was a user choice as

> >to the time-scale they wanted. There are three choices:

>

> That is not "solving" the problem, that is "kicking the can down

> the road" :-)

>

> But then again, Java is a different environment, and I think we

> should look at Java as implmented on top of OS services, not

> the other way around.


Exactly why I was asking about the purpose of this API. I'm not seeing
it as a time API, but as a clock API. A time API would have other
constraints and functions. My concern with what you have proposed is
that the second part (the time-zone part) does imply a time API, but
without sufficient control.


> >I don't believe its what users *want* (it forces every query of

> >seconds to have to handle leapsecs, which is undesirable for API

> >usability).

>

> Remember, this may not be the API the user sees, there would very

> likely be an intermediate level of "convenience" functions.  What

> I am trying to describe is the _lowest level_ of timekeeping service

> available, the one that can support "all of the above".


I think that the proposal/spec needs to be very clear on its goals in
the writeup.

FWIW, the Java world already has its own copy of the time-zone data
files, and the JSR-310 spec makes use of the leap secs data from those
as well. But not that is direct use, not use of the OS copy. (And
there is a vague plan to allow over-the-air updating of time-zone
data, which would include leapsecs, but again, only to Java)

The JSR-310 spec effectively only requires a clock source from the OS.
The API allows the source to be TAI (secs, nano-of-sec), UTC (mjday,
nano-of-day) or 86400 (something that provides 86400 secs per day in
line with the standard civil time, which should ideally be smoothed in
some way at leap second).

Currently, my view is that the low-level API that you are defining
should offer all three of the above, as they are the building blocks
for everything else. An implementor would code one, and write
conversions to the other two in likelihood, but it means that you are
forcing less of existing implementations. ie. think of it as a
possible transition approach.


Finally, I do think that if its called TAI, then it should use the TAI
epoch. BTW, the UTC before 1972 issue is a problem. FWIW, JSR-310
currently defines the TAI-UTC offset as always 10s before 1972, even
though that is obviously not historically accurate.

Stephen