Hi Tom,
> You keep saying this, but there's only one kind of clock and one kind of time.
The folks who organized:
http://fqxi.org/conference/2011
might disagree. However, I was (and always have been) speaking in terms of
system engineering requirements.
> When you get two or more clocks you have the ability to compare them and
> measure time interval among them.
And Einstein might have something to say about the nature of this problem
(simultaneity), not just its solution (standard synchrony):
http://plato.stanford.edu/entries/spacetime-convensimul/
On the engineering side, this is an issue for NTP, for instance, which cannot
get a grip on a pragmatic protocol without making assumptions about what it
*means* for two clocks to be set to the "same time". I'm typing this from
Oxford in the morning hush before the first session at:
http://www.physics.ox.ac.uk/IAUS285/
I just got off the phone (well, Skype) with my wife. It is still last night
for her, many timezones to the west. The meaning of civil time certainly has
something to do with the rotation of the Earth.
(I even considered and rejected bringing Dave Mills' excellent book along:
http://www.eecis.udel.edu/~mills/book.html
Really gotta get the second edition.)
> Time interval is often an integer (cycles) and fraction (of cycles). What you
> are calling time of day is merely time interval, where the start time is an
> artificial agreed upon point in the past.
Well, make that "natural" agreed upon point :-) Perhaps "arbitrary" is a
better word here. Regarding the "in the past" part, see also:
http://preposterousuniverse.com/eternitytohere/
An engineering requirement for a database of intercalary adjustments (in either
offset or rate or both) will always reappear. The nature of a requirement is
that it is inherent in the description of the problem. Attempting to ignore a
requirement does not make it go away. Stating (as some here undoubtedly will
do) that the requirement is not actually required also doesn't make it go away.
A requirement is not a specification. The former describes the problem. The
latter is related to a proposed solution.
The concept of operations for civil timekeeping is time-of-day. And
time-of-day *means* mean solar time. If you want to make time-of-day mean
something else you have to convince the other stakeholders (everybody on the
planet whether they know it or not) that time-of-day can mean any random rate
and/or offset to which a timepiece can be set. This is a rather high bar to
clear.
> But it's still all time interval.
Coherent systems engineering is precisely the way to tame these complexities
(see also the SOFA thread). All of the long term participants on this list
have enough of a common apprehension of the various details to mix and match
them toward our differing visions of the problem. What we lack is precisely a
common vision of the problem. The fundamental goal of systems engineering is
to provide that common vision.
Having first labored to reach a shared understanding of the concept of
operations (in engineering terms, not the big philosophical discussions) of
civil timekeeping, then we would be able to coherently pursue an engineering
process to converge on a consensus solution to that single problem.
In engineering there is a single shared problem space and many different
overlapping (and even sometimes disjoint) solution spaces. This long
conversation (in the Long Now sense:
http://longnow.org/seminars/02010/oct/16/long-conversation/) that we have been
having over the past dozen years is only just now getting around to building a
shared vision of the problem. The nature of time is a very fundamental issue -
it isn't surprising that it would take a lot of time to converge even on that
small sliver of its nature wrapped up in civil timekeeping.
To not work at cross purposes, the only resolution is to reach a common vision
of the purpose. This is not only the best way to reach a novel new solution -
it is the fastest way to do so.
Rob
PS - note that nowhere above do I mention leap seconds. Leap seconds are a
means to an end in one family of possible solutions to the problem of
time-of-day. By all means let's discuss alternatives. But we won't make
progress on finding different classes of solution until the nature of the
problem of time-of-day is held jointly in common between us.
_______________________________________________
LEAPSECS mailing list
[email protected]
http://six.pairlist.net/mailman/listinfo/leapsecs
