[LEAPSECS] LEAPSECS Digest, Vol 82, Issue 6

[Joseph Gwinn]

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.

Joe Gwinn