[LEAPSECS] Java API [was Re: USWP7A docs for 2013 September meetings]

[Stephen Colebourne]

On 19 August 2013 22:00, Warner Losh <imp at bsdimp.com> wrote:

> On Aug 18, 2013, at 3:29 AM, Stephen Colebourne wrote:

> Making things not match reality because users don't expect it either means that we've defined reality wrong ... or it means that you are being too clever.


Or simply that 99% of people have a different view of reality. For
most people there are 24 hours in a solar day, each of 60 minutes of
60 seconds. They don't think beyond that. They don't trouble
themselves with leapsecs, except when the news organization points it
out on New Years Eve (and then they forget about leapsecs again).

ie. No-one cares about leapsecs

(The issue of this list in general is not whether people want
leapsecs, but whether people want the solar day to define time.
Leapsecs are a means to an end)


> My main point is that the three biggest issues that I ran up against when trying to implement a real-time system that got leap seconds right were (a) APIs that don't grok leap seconds at all (POSIX's time_t), (b) people thinking "it is only a second" and why bother getting it right and (c) nobody publishes TAI (UTC is what's published, even in GPS receivers that have an underlying TAI-like timescale), and the offset between TAI and UTC isn't always available in a timely fashion....


Bear in mind that a low level C or kernel API should make different
choices to a high level business/enterprise API to be used by 9
million developers of variable quality.


>> The funny thing is that if there had been no effort to remove leap

>> seconds, then the API might have been designed such that obtaining TAI

>> and UTC with leapsecs was easy. Those arguing for leapsec abolition

>> actually made the API "worse" from their perspective.

>

> I don't see how this follows. APIs should be designed for the system as it is today, not how it might be tomorrow.


It specifically came up. We had an API that modelled the TAI, UTC and
UTC-SLS time-scales. But the extra complexity couldn't be justified
when UTC might disappear in 2 years time. It also added another choice
to the user, which would result in some users trying to use the
complex time-scale classes when they'd be a lot better off just
ignoring leapsecs.


>> On the positive side, I would say that the API (a) understands what

>> leap seconds are, (b) defines how the system is supposed to cope when

>> they occur. That is a whole lot more than Java and many other

>> libraries have done before.

>

> I'm confused now. I thought you'd said that this info wasn't available at all. Perhaps rather than a summary, you could post a pointer to the API. That is unless the API explicitly says "always hide leap seconds from users in this way"... I guess it is better, in some ways, since it means I know that I can never get them right.


Zefram explained it well. It is only on the border that leapsecs
matter. Within the API, all days have exactly 86400 "seconds" as
defined by the Java time-scale, which is based on UTC-SLS. See here
for the spec
http://download.java.net/jdk8/docs/api/java/time/Instant.html

Stephen