Re: [LEAPSECS] building consensus

From: Zefram <zefram_at_fysh.org>
Date: Sun, 4 Jun 2006 10:32:50 +0100

Rob Seaman wrote:
>Suggest such an activity needs a more measured beginning.

I'm all for that. The whole point of this activity is to be more measured
than what has gone before. I want to establish what the *problem* is
before deciding whether leap seconds or the absence thereof are part of
the solution.

> Also suggest that the assertions
>need to be much more carefully nuanced.

Yes, they certainly do.

>Say rather that our shared understanding of time must become more
>sophisticated. Certainly, some applications - even some time
>applications - require more or less detailed timekeeping models.

That's a good statement. Can we go further and work out a specific
ontology of topics in timekeeping? I'm thinking of the way that the
IAU resolutions defining the modern coordinate time scales explicitly
identify general relativity as their theoretical basis.

John Cowan wrote:
>> Post-1972 UTC, counting TAI seconds while maintaining a "day" cycle that
>> closely matches the phase of UT1, is directly analogous to calendars
>> that count days while maintaining a "year" cycle that closely matches
>> the phase of the tropical year.
>
>If this means that leap seconds 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?

>> Unix time, as standardised by POSIX and as commonly implemented, is a
>> faulty encoding of UTC. The fault is that Unix time readings repeat,
>> and so are ambiguous, near positive leap seconds.
>
>"Faulty" is a word implying, well, fault. The no-fault view is that it's
>an *ambiguous* encoding. Whether that is faulty cannot be evaluated
>without reference to a purpose.

Being ambiguous between adjacent seconds seems inherently faulty to me.
Would a qualifier "... for 1 s-precision timekeeping" clarify this
adequately?

>> Readings of UTC cannot be directly represented by a single linear count.
>
>Of course they can be. The question of what you can do with that
>linear count is another matter.

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".

>Unix time (better: Posix time) *is* monotonically nondecreasing,
>provided you set it with NTP and not by brute force.

Not necessarily. The Mills kernel model makes the Unix time perform a
backward step of 1 s during a positive leap second, and does so using
data supplied by NTP. I've seen Linux 2.4 perform this step (but during
a simulated leap second, not a real one) in the course of testing some
of my timekeeping code.

I think we're talking about completely different aspects of Unix
timekeeping here.

>> Some applications assume that Unix time is a linear scale suitable for
>> interval calculations, and so are poorly served by the encoding of any
>> form of UT in Unix time.
>
>You should add "to a precision of 1s". Applications whose precision
>requirements are, say, 1 day, don't have a serious problem.

OK.

Tom Van Baak wrote:
>> UT1 et al are not really measures of time, but of angle (of Terran
>> rotation).
>
>To some degree yes, but don't they also include minor
>corrections (polar motion, longitude, etc.) and so at one
>level they already depart from raw angle measurement
>and instead are trying to act like clocks?

I describe them as smoothed angle measurements. If one wants to use one
of them as a clock then one would want to choose the smoothest one, hence
the popularity of UT2 for timekeeping in the pre-atomic and early atomic
era. I don't think the smoothing takes it away from being fundamentally
a measure of angle, although UT2 is indeed not a "raw angle measurement".
UT0 and UT1 are both raw, AIUI, but measure different angles. For that
matter, apparent solar time is a raw angle measurement too.

-zefram
Received on Sun Jun 04 2006 - 02:33:12 PDT