On Wed, Apr 8, 2015, at 15:46, Paul_Koning@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).