[tz] Leap seconds puzzle

[random832 at fastmail.us]

On Wed, Apr 8, 2015, at 15:46, Paul_Koning at dell.com wrote:
> Thanks much!  That sure is not clear from the RFC.  So that explains
> things: it means that a POSIX system that is an NTP client will track
> UTC, leap seconds and all, except for a short while just after a leap
> second occurrence because at that point the NTP client machinery will be
> adjusting to the one second phase shift.

NTP is able to give the client advance warning of an upcoming leap
second, and the client ntpd can do various more sophisticated stuff to
try to "smooth out" the leap second, since having the clock stop for a
second - or worse, for sub-second timestamps to go backwards by a second
- is undesirable. More undesirable than having the clock be deliberately
inaccurate (by less than a second) for an extended period.

POSIX itself does not comment on what should happen to the clock a leap
second, nor does it mandate any particular level of accuracy for the
system clock, nor does it mandate that the system real-time clock should
be monotonic.

But, yeah, a POSIX system will never report a time with a second outside
the range of 00-59, and difftime will always return a multiple of 60 for
timestamps that are a whole number of minutes apart (and these values
will be the same mod 60 as the seconds component of their broken down
UTC time, etc).