[LEAPSECS] any other parties?

[Zefram]

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

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.

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.

-zefram