[LEAPSECS] any other parties?

[Warner Losh]

On Jul 9, 2012, at 6:51 AM, Zefram wrote:


> Nero Imhard wrote:

>> Is that really the Unix way? I always thought that "proper"

>> implementations didn't step back, but paused the time for a second at

>> :59:59 (while still having subsequent calls of gettimeofday return

>> increasing values by adding microseconds as needed).

> 

> POSIX implies that the :59:60 second appears identical to the :00:00

> second; i.e., the clock steps back at the end of the leap second.



:59:60 doesn't exist in POSIX time_t.  It does exist as a non-normalized time that is then normalized to 00:00.  The difference is subtle, but can be explained by the feature in posix of being able to add N units to and struct tm member and have the system figure out what the next time is.  Some systems took this non-normalized form to repeat the first second of the day even, but it is a weak argument, since the second properly belongs to the prior day....



> The NTP model (and practice of some implementations) says that the clock

> should step back at the start of the leap second, making the :59:60

> second appear identical to the :59:59 second.  In either case, if you

> look only at the integer seconds portion of the clock then you could

> interpret it as "paused", in that you get the same time_t value for a

> period of two seconds rather than the usual one, while the time_t value

> monotonically increased throughout.  But if you look at the microseconds

> from gettimeofday, you see the microseconds values [0,1000000) occur

> twice in succession, depicting a repeat of a second rather than a pause

> or an extra-long second.


This is the FreeBSD behavior.  Tick normally up to the leap second cut over and step time back a second at the top of the :60 second.  Ugly stuff that...  But one of the least disruptive behaviors.


> Also worthy of note is Linux 2.4 behaviour, where the integer seconds

> value is non-monotonic.  The time indicated jumps back by a second at

> about :59:60.005; it's not aligned to the second boundary.  This sequence

> only makes sense if you look at the complete (integer+fraction) time

> value and treat the discontinuity as a jump of the clock.


Fun...


> I've seen it suggested that a leap second could be indicated in the

> usual Unix structures by having tv_usec take the range [1000000,2000000)

> or tv_nsec the range [1000000000,2000000000).  With the integer seconds

> value staying at :59:59, this would be mathematically coherent as well

> as successful in uniquely identifying the leap second.  This seems to

> be what you think is standard behaviour.  I'm not aware of anything

> implementing this mechanism.  gettimeofday and friends never do.  Also,

> think about how much would break if it occasionally saw tv_usec/tv_nsec

> with an `impossible' value.


Yes.  And for time_t consumers, it gets interesting too, depending on if they truncate or round...  As with anything in leap seconds, implementing them in a POSIX context requires judgement into what you break....  Because no matter how clever your scheme, you break some invariant.  The trick is breaking the right invariants for your application.  Sadly, there is no universal thing you can break that works for everybody.

Warner