[LEAPSECS] New time scale name

[M. Warner Losh]

In message: <1281716746.1929.51.camel at localhost>
            Paul Sheer <p at 2038bug.com> writes:

: 

: > Best?  This isn't an 'upgrade' at all, but rather returns to the

: > 1960's practice of having "rubber" seconds.  The UT1 second doesn't

: > tick at a constant rate, so you have to constantly update the notion

: > of the second.

: > 

: 

: in the 1960's we didn't have the Internet - which is the most

: widely used method of synchronizing clocks.


Right, and it ticks based on UTC right now.  Many systems have
stability that are in excess of UT1's stability and moving to UT1
would break the statum 0 ones.


: > : And drop further leap seconds of course. I have tried, but can't

: > : find a system that would break because of this. 

: > 

: > All the stratum 0 NTP servers would break. 

: 

: 

: no, under my proposal the NTP servers would be "upgraded" to broadcast

: TAI plus some smoothed out delta to match UT1. This is not a

: "breakage". The migration would happen on a date where UTC and

: UT1 exactly match which happens every couple of years. If the

: NTP servers that are atomically based (or GPS based) had their

: software upgraded first, then the time would be automatically

: propogate to all other NTP servers.


You misunderstand the problem.

The problem is that GPS tracks GPS which track TAI.  There's no UT1
information broadcast over GPS.  Therefore, an NTP server that is
slaved to GPS cannot possibly track UT1 because the UT1 offset
information is not available to it.

There's two problems here: UT1's frequency stability is inferior to
GPS', but thankfully the stability is better than NTP normally gives.
This stability can be a problem if you want your NTP server time to
match the time that is going out other spigots (usually just PPS).

So how do you track UT1 if your time source is UTC?  The only way to
do that is to get UT1 offsets often and model the time tracking based
on that.  


: >  The vast majority of them

: > are based on GPS, which is based on UTC and cannot be based on UT1

: > since that would destroy the accuracy of GPS.  If you mandate UT1 be

: 

: GPS satelites have their own atomic clocks that keep in sync such

: that GPS = TAI + 19

: 

: GPS devices use this clock for their position calculations - 

: this clock would not change under my proposal.


This is good.  Changing all the GPS units in the field would be
difficult.
 

: In actual fact under my proposal GPS could broadcast in their

: offset field:

: 

:     floor(UT1 - TAI - 19)


Which is exactly my point: You'd have to augment the GPS almanac with
additional information.  This sort of change would take years to 


: They wouldn't have to worry about leap seconds any more.


Yes and no.  UT1 - TAI time still has an evolving offset, just like
UTC - TAI time.


: Hand-held GPS devices would just show the wrong time by <1s.


Why concede this point?  If you have a UT1 - TAI offset, you can
correct it.


: > broadcast by NTP servers, then you'd need to find a way to get highly

: > accurate (to 1ms) DUT1 data.  This information isn't available in real

: > time (although good estimates are).  This information also isn't

: 

: it is LEAP SECONDS that are currently not available!  :-)


That's also a problem in the current system, yes.  However, the
summary information for leap seconds is available.  In the terrestrial
broadcast formats, it is "leap pending", while in the GPS data stream
it is current offset and future offset change.  These are a complete
table of leap information, but are sufficient to recover time from a
GPS receiver (at least for the next 50ish or 100ish years when we'll
overflow the leap offset fields). 


: Why would a function that produces a smoothed out UT1 be

: any worse than a function that produces leap steps?

: 

: The latter is what we currently have.

: 

: My proposal is that we switch from a "smoothing function" that has

: sharp steps in it to a smoothing function that is well.. smooth!


UT1 isn't a completely smooth function.  Currently, it is calculated
for yesterday, with an estimate for the next several days.  This
function isn't smooth, but rather has more smaller discontinuities
than UTC does today.


: 

: > broadcast as part of GPS' almanac.  There's a large number of NTP

: > based on GPS networks that aren't Internet connected, so that would

: > break them.

: > 

: > : 2nd option is to keep leap seconds but upgrade the NTP and radio

: > : protocols to give more warning - not 10 years warning, just *more*

: > : warning. 

: > 

: > This is the sensible option that many people have been advocating.

: > However, to do this right, you'd have to put more funding into

: > modeling the earth, and also accept that you might, for periods of

: > time, have > .9s divergence between UT1 and UTC.  In order to do that,

: > you have to deal with how to broadcast that information.  There are

: > sources of this data on the Internet, but the data format doesn't

: > allow for > 1s representation of |DUT1|.

: 

: 

: What I actually meant was this:

: 

: NTP packets have just one flag in them that says there is a leap

: second at the end of the current DAY.

: 

: This is insane.

: 

: It should have an array of integer fields to say WHEN there are

: leap seconds in the coming YEAR.


NTP has two mechanisms for leap seconds.  First, it has a 'Leap at the
end of the day' flag.  This flag can be turned on any time in the
protocol, but current ntpd implementations filter this flag so it is
only honored on December 31 and June 30th.  Second, ntp can transmit
the entire leap second table, which has no time delta restrictions.


: A YEAR notice is totally do-able. No extra "modeling of the earth"

: is required.  :-)


A year notice is absolutely not doable at all today.  Leap seconds are
announced in early July for December 31, and in January for June
30th.  There's no way to do a year out today, officially.

Unofficially, the IERS folks could likely model the earth's rotation
out not just 6 months, but closer to a few years.  There's been
informal discussions that have been reported here (or one of the other
mailing lists) that suggest 1 year is easily doable, 2 years would
start to hit the 95% confidence interval, and beyond that it becomes
less reliable.  But that's using very simple models of past leap
seconds, and not the higher order (13th degree curve fit) equation
that some folks have tried to use to model the behavior.  With that,
it is suspected they could move things out more.

But there's a reluctance on the part of the IERS to move beyond the
6month look ahead for a variety of reasons.  Some of this reluctance
is due to funding, other due to liability.  What if they predict out a
few years and the earth does something unexpected, or they are
otherwise wrong?


: If this is implemented this means that clients need only query

: once a year to get this info.


Unless IERS changes its Bulletin C frequency, they have to do it at
least 2x a year.


: Currently they have to query EVERY DAY! And this is the REAL problem.


Actually, no they don't.  They can get the leap second table from the
NTP server.  There's some admin problems with this, but the
functionality exists today.

Warner


: -paul

: 

: 

: 

: 

: 

`<`