[LEAPSECS] New time scale name

[Paul Sheer]

> 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.



> : 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.



>  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.

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

    floor(UT1 - TAI - 19)

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

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



> 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!  :-)

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!



> 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.

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

If this is implemented this means that clients need only query
once a year to get this info.

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

-paul