In message: <[EMAIL PROTECTED]> John Cowan <[EMAIL PROTECTED]> writes: : Zefram scripsit: : : > >If this means that leap secounds and leap days are analogous, then I : > >suppose so. If it means something else, I don't understand it. : > : > That's what I meant. Can you suggest a clearer wording? : : "Leap seconds (after 1972) are closely analogous to leap days."
"Leap seconds (after 1972) are closely analogous to irregularlly happening leap days." might be better, since leap days have a rule, while leap seconds are scheduled. : > Being ambiguous between adjacent seconds seems inherently faulty to me. : : The designers of Posix time thought it was more important to preserve : the property that dividing the difference between two time_t values : by 60, 3600, 86400 would give minutes, hours, days. That's the one property that Posix time_t does not have. The difference between time_t's that cross a leap second are off by one second, and therefore do not start with the right answer to do the division... POSIX time_t definition effecitvely omits leap seconds from the time scale (by playing them twice, or pretending the second happened), the difference between two time_t's always gives a duration adjusted for the leap seconds that happen, rather than the actual duration. : > Are you thinking of linear counts such as POSIX time, where the : > representation is ambiguous? I was implicitly excluding those, on the : > grounds that they don't count as a "representation". It's also not : > "linear". : : No, it isn't. But that doesn't mean you *can't* construct a numerical : representation of UTC time: say, the number of UTC seconds since : 1972-01-01T00:00:00Z. It would be better to say the number of SI seconds since 1972 rather than UTC seconds, I think. I use a timescale like this at work to ensure that duration calcuations over leap secondsd are correct. Warner