On 19 August 2013 22:00, Warner Losh <[email protected]> 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 _______________________________________________ LEAPSECS mailing list [email protected] http://six.pairlist.net/mailman/listinfo/leapsecs
