[LEAPSECS] USWP7A docs for 2013 September meetings

[Warner Losh]

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


> On 17 August 2013 23:01, Warner Losh <imp at bsdimp.com> wrote:

>> On Aug 14, 2013, at 2:36 AM, Stephen Colebourne wrote:

>>> It is therefore essential to prevent leap seconds from being exposed

>>> to 99% of developers.

>> 

>> This attitude is why no real systems get leap seconds exactly right :( We do not protect programmers from leap days, and they get them right nearly always. Protecting programmers from leap seconds is one of the biggest mistakes people have made over the past 40 years, since now we have generations of programmers that program against a standard that doesn't match reality, and it should surprise nobody that it is never right.

>> 

>> I know you've had lots of experience with designing APIs, but I think that you came to the wrong conclusions by catering to ignorance rather than educating the ignorance away.

> 

> The thing to bear in mind is that you are an atypical user. Most users

> probably don't even know what a leap second is. Those that do don't

> really care and won't think about it when designing their code. In

> addition, most users never read the documentation. Given this,

> education simply isn't realistic. And including them would result in a

> whole world of bugs that occur very infrequently.


I guess we have a philosophical difference here then. Making things not match reality because users don't expect it either means that we've defined reality wrong (which is why you'll seem me argue against leap seconds in other forums), or it means that you are being too clever. By precluding leap seconds altogether, you make it impossible to get them right.

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

Ideally, there's be a way to support people that don't care without kicking people that do care to the curb...


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


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

Warner