[LEAPSECS] USWP7A docs for 2013 September meetings

[Warner Losh]

On Aug 15, 2013, at 1:23 AM, Stephen Colebourne wrote:


> On 14 August 2013 19:24, Hal Murray <hmurray at megapathdsl.net> wrote:

>> 

>>> The approach of smothing any leap is what Java version 8 will be defined

>>> using (which is a definition that also handles abolition of leaps, should

>>> that occur).

>> 

>> Is there a way to ask for the non-smoothed time?

>> 

>> Will the smoothing recipe be standardized or does each OS/library get to do

>> it their own way?

> 

> The answer is complicated.

> 

> We define a Java time scale that equates to UTC-SLS. Clocks are

> supposed to follow the time-scale. As such, if you have separate

> knowledge of leap seconds, then you can reverse engineer the actual

> leap second. There is no direct way to get non-smoothed time (we

> considered such approaches but felt that too few users actually care

> about leapsecs to justify it)

> 

> However, the underlying clock that Java currently has is completely

> ill defined wrt leap seconds. As such, there is no way to provide an

> implementation at the higher level that accurately implements the

> spec. This is of course weird, although most people just don't care.

> 

> What users can do is implement their own clock. If they have access to

> a leap-second aware time source, then they can accurately implement

> the Java time-scale.

> 

> Potentially, a future version of Java might provide a more accurate

> low-level clock if the OS has one, which would allow the spec to be

> correctly implemented.


So you've defined the API so there's no way for an application to get a leap second correct? Seems very ill advised. Again, this attitude is why nobody gets things right and why leap seconds are such a pain to deal with. "We'll just smooth them over" has been the pervasive attitude for the past 40 years of leap seconds, and it has gotten us a bushel basket full of bugs.

Hopefully nobody will use your API when they need legal time...

Warner