[LEAPSECS] Synchronization requirement?

Rob Seaman seaman at noao.edu
Thu Nov 13 02:51:02 EST 2008


Brian Garrett wrote:


> I was wondering when somebody was going to mention sniper bids.

> These are automated and require reliable synchronization so as to

> get bids in at literally the very last second.

> [...]

> laws that reference civil time to actual timescales, instead of

> "mean solar time of 15 degrees east longitude" and the like.)


I'm tempted to pen a defense of mean solar time as an "actual
timescale". What does "actual" mean, if not something that can be
measured from first principles?

The real issue here, however, is transport of time signals, not their
definition. From an architectural standpoint, it isn't immediately
clear that a special purpose timekeeping application like an online
auction has a requirement for close synchronization with an external
timescale, so much as a requirement for close synchronization among
its own clients. For example, a traditional auction takes place at
some specific place and time, but once the auction starts for a
particular lot, the bidders either physically present or participating
by phone proxy are bound only by the cadences of the auctioneering
process, not by an external clock.

A lot of the issues that we've discussed on this mailing list share an
underlying etiology of choosing the wrong timescale for a particular
application. With civil timekeeping we might argue, for instance,
over whether an inappropriate choice of timescale is being forced on
one group or another. But for many timekeeping applications, the key
requirements are for relative, not absolute, synchronization.
Overloading the project requirements by demanding tight compliance
with some absolute standard may result in sacrificing performance
elsewhere in the system.

To be more specific, there is nothing ebay can do to enforce that
their customers have computers with properly set system clocks. What
ebay could do is build a dedicated NTP service into their system, and
promulgate their own time signals tying their servers as tightly as
needed to user client applications. Whether ebay's clocks are then
themselves tied to external time signals is a completely separate issue.

Which is all to say that it might benefit the larger discussion to
question a few underlying assumptions, to vet and perhaps reject some
premises. I know why astronomers need access to universal time - it
provides a utilitarian representation of Earth orientation metadata.
Just so with navigation, tide tables, wind and weather and other
diurnally tied phenomena. We've also mentioned other legal, economic,
political, etc. use cases for distributed timescales, diurnal or not.
What are the use cases for tying widely disparate systems jointly
together, however?

When there is an election, the public needs to know when the polls
open and close. Traders need to know when the stock market opens and
closes. Computer databases and code build tools need to interoperate
across local or wide area networks. But why do we assume that these
several purposes need to be tied together?

Is this a requirement - or rather only a presumptive convenience?

Rob Seaman
NOAO



More information about the LEAPSECS mailing list