[LEAPSECS] LEAPSECS Digest, Vol 82, Issue 6

[Warner Losh]

On Aug 11, 2013, at 12:43 PM, Joseph Gwinn wrote:


> On Sun, 11 Aug 2013 12:28:39 -0600, Warner Losh wrote:

>> 

>> On Aug 11, 2013, at 12:10 PM, Joseph Gwinn wrote:

>> 

>>> On Sun, 11 Aug 2013 11:50:34 -0600, Warner Losh wrote:

>>>> 

>>>> On Aug 10, 2013, at 4:43 PM, Daniel R. Tobias wrote:

>>>> 

>>>>> On 10 Aug 2013 at 21:02, Poul-Henning Kamp wrote:

>>>>> 

>>>>>> I'm simply distinguishing systems which know about leap seconds from

>>>>>> those which are totally unaware of their existence.

>>>>> 

>>>>> For the vast majority of systems, being totally unaware of leap 

>>>>> seconds is the most sensible way to run them. Once a leap second 

>>>>> happens, it will be part of the "time drift" between the local clock 

>>>>> and whatever external standard it syncs to, and is taken care of the 

>>>>> same as all the other slippages (which can add up to a number of 

>>>>> seconds if the local clock is not very accurate and/or the time 

>>>>> between re-syncings is long). The jump on re-syncing can be done as a 

>>>>> sudden discontinuity or smoothed out depending on what is least 

>>>>> disruptive. Only a tiny handful of highly specialized applications 

>>>>> need anything more constantly precise than this.

>>>>> 

>>>>> For everybody outside those handful of specialized applications, 

>>>>> attempting to deal "correctly" with leap seconds at the moment they 

>>>>> happen is both unnecessary and likely to cause more problems than it 

>>>>> solves.

>>>> 

>>>> The problem with this attitude is that it makes it hard for people 

>>>> that want to implement leap seconds correctly from off-the-shelf 

>>>> components to do so. If most of your OS ignores leap seconds, how are 

>>>> you supposed to properly implement them? If POSIX time_t refuses to 

>>>> acknowledge that they exist, how can an implementor cope with 

>>>> representing the second that's leaping? It continues the dismal state 

>>>> of the art which is very hard to row upstream against.

>>>> 

>>>> That's another reason, btw, people get leap days right: being off by 

>>>> one full day is a really big deal, and the cost to get it right is a 

>>>> dozen instructions (or about 30 characters in the source). Getting 

>>>> leap seconds right, at least on a unix/POSIX system is impossible by 

>>>> definition of time_t.

>>> 

>>> The POSIX standard in fact forbids it, precisely to escape the time 

>>> wars.  The basic intent of POSIX time is self-consistent file 

>>> timestamps, so make will be able to deduce causal order.

>>> 

>>> However, POSIX allows an implementation (read, operating system) to 

>>> define as many named clocks as desired.

>>> 

>>> If you are interested, there was a long thread on this in TimeNuts.

>> 

>> POSIX requires that you break either the naive math, or have no way 

>> to represent the leap second. One of these things must be broken, and 

>> defining a new clock won't solve that at all. And having many 

>> different clocks with the same base type also is likely dangerous 

>> since it becomes too easy to cross the beams and call other functions 

>> that don't know about the special clock to present the time to the 

>> user.

>> 

>> However, experience has shown that fewer programs are broken by 

>> breaking the naive math and using the 'right' timezones to present 

>> the data to the user correctly.

>> 

>> But the problem with doing that is there's a table that must be 

>> updated to have it work properly, and experience with past leap 

>> seconds has shown that this table doesn't get updated (which is the 

>> basis of my complaints that UTC is an observational rather than a 

>> computation calendar). If we knew leap seconds several years in 

>> advance, the deployed systems would have a longer shelf life and 

>> these systems would work better. Alternatively, having a better leap 

>> second table update infrastructure that was secure and reliable would 

>> help, but there's nothing widely deployed today that does this 

>> (despite this information being available, it isn't securely 

>> available)..

> 

> You have it basically right.  But securely available wasn't the real 

> problem then, it was automatically available without help from baffled 

> users that was the real problem faced by the vendors, who know that 99% 

> of their customers could not define a leap second even if their life 

> depended on it.


If you can securely update it, then you can automatically securely update it. But if you can't trust the source, then it introduces big security problems as people can mess with time.

Having different types of clocks isn't really supporting leap seconds either. It is yet another half-assed kludge in the never ending series of hacks, kludges, willful blindness, general apathy and confusion that surrounds getting leap seconds right.

Warner