[LEAPSECS] USWP7A docs for 2013 September meetings
imp at bsdimp.com
Sat Aug 17 18:10:01 EDT 2013
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...
More information about the LEAPSECS