[LEAPSECS] Lets get REAL about time.

[Poul-Henning Kamp]

In message <CACzrW9Cv16zyYUU802fxq=C3-Pxrcz6mEVZpabgjhb_xEYCsUg at mail.gmail.com>
, Stephen Colebourne writes:

Could Java treat the binary128 as an opaque type and provide
subtraction/addition primitives for it ?


>The Java spec currently uses 64 bit seconds and 32 bits for

>nanoseconds. Only one person so far has asked for attoseconds, and I

>think thats overkill myself.


It may be for Java, but not in general.  In particular somebody will
have to implement the timekeeping code and for that you need 64 bit
of fractions.  That is of course not the same as "we also need that
in general", but since 96 bit variables are rare.


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


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


>> In all other cases, this timescale represents elapsed time in SI

>> seconds, and two successive calls to this function will always

>> return two timestamps in increasing order.

>

>A guarantee of always increasing would be useful.


That is what I tried to express.


>> We treat UTC as another case of the larger class of civil timezones.

>> Converts the timestamp to "broken down time" in the specificed

>> timezone, applying leap-second corrections, daylight savings time etc

>> as directed by the "tz" paramter.

>

>I'm sceptical of the time-zone approach. I find a user demand to

>record instants in time, but believe that they are days of 86400

>"seconds". Does this API return a "broken down time" (fields) with a

>second-of-hour of 60?


Yes, it will say 23:59:60 during a leapsecond.


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

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk at FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.