I think you (Guy) have fairly accurately covered the issue. I agree that the POSIX rationale is confused, and wonder why they did not seek guidance from the C standards committee since we did thoroughly research and analyze this issue before settling on the specification in the C standard (which intentionally contains one or more small ambiguities to accommodate systems that cannot get time conversion precisely right for whatever reason). The intention is for struct tm to contain the "user-interface" time components and for all computations to be performed using corresponding time_t data, which in the general C standard is a magic cookie but which is supposed to be a uniformly ticking clock value in POSIX (with the number of ticks per second a system macro). Standard C provides a difftime() function simply because some systems may not have as clean an internal representation of time_t as UNIX does. The oscillators is supposed to tick uniformly (with very tiny tweaks to track an accepted time standard, but no "leaps" of any sort), and time_t should be an affine function of the number of accrued clock ticks. If POSIX has managed to require that the internal clock jump back and forth then it has a bug that should be fixed. "Leap seconds", like Daylight Saving Time, is an artifice due to people having an imperfect handle on the underlying nicely flowing physical phenomenon of time. That's the model behind the C standard and should be the one behind POSIX if it is to be a good specification.