Re: [LEAPSECS] building consensus
In message: <20060605021717.GA21857_at_ccil.org>
John Cowan <cowan_at_ccil.org> 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
Received on Sun Jun 04 2006 - 21:59:19 PDT
This archive was generated by hypermail 2.3.0
: Sat Sep 04 2010 - 09:44:55 PDT