[LEAPSECS] Consensus!

[Warner Losh]

On 02/23/2011 04:04, Ian Batten wrote:

> On 22 Feb 2011, at 22:46, Warner Losh wrote:

>

>> On 02/22/2011 15:33, Rob Seaman wrote:

>>> On Feb 22, 2011, at 2:31 PM, Warner Losh wrote:

>>>

>>>> the 10-year horizon solves many problems with leap seconds.

>>> I just wanted to highlight that significant consensus has indeed been reached!

>> I've been saying this on and off for a while...  I'd prefer there be no more leap seconds,

> But in which case, your navigation scenarios evaporate, because UTC with no leapseconds would be of no use to people using it for celstial navigation.  You've got scenarios which have as a requirement the immediate production of UTC, but that's because UTC is a time scale which has two useful properties (SI seconds and close alignment to UT1) than other time scales don't.  If you unhinge UTC from UT1, which is the effect of removing leap seconds, why would navigational customers need it?  You cited Loran stations: why would a Loran station need a timescale that is explicitly _not_ connected to celestial motions?  If they want a readily available timescale to synchronise to amongst stations and consumers, GPS time (or any other mutually available time) will do; if they want a time scale to allow checking of events against transits and zeniths, they need UT1 or UTC.


If you knew the error between the clock and UT1 was 1.5s, you could 
correct just fine.

Funny you should mention Loran time.  That's *EXACTLY* what LORAN time 
does.  It stopped accumulating leap seconds in 1972 when they went to 
full-second jumps.  It does have anything at all to do with the earth's 
rotation, and is completely independent of that.  It  has a number of 
stations pulsing out at regular intervals that are mostly relatively 
prime to the other chains of stations.  With one chain, you can get a 
fix based on the difference in time of arrivals of each of the pulses.  
With multiple chains, you can reduce your error by averaging the 
solutions together.  UTC doesn't enter into it, except when you need to 
restart the chirping of a station.  Then you take the UTC time, add back 
in the leap seconds and do modulus arithmetic to know where to start the 
pulse chain to be in sync with what all the LORAN receivers expect.  UT1 
is simply not relevant at all, and in fact hurts your navigation 
solutions if you were to try to use it since it ticks at irregular rates.

Warner