[LEAPSECS] leap smear

[Rob Seaman]

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.