[LEAPSECS] Synchronization requirement?

[Rob Seaman]

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