[LEAPSECS] leap second roundup 2017

Mon Oct 23 18:31:50 EDT 2017

On Mon, Oct 23, 2017 at 3:42 PM, Brooks Harris <brooks at edlmax.com> wrote:

> On 2017-10-23 02:07 PM, Warner Losh wrote:
>

> Never has been really, but it was the objective for centuries. Local time
> is obviously a gross approximation, but a very useful one. Before atomic
> time, navigation time (the almanacs) and "civil time" were largely one and
> the same. Leap Seconds decoupled them.
>

Before the 1950's we had no clue the two could be different. The almanacs
were based on how well chronometers could be made, which was on the order
of one second per day or month (especially for mobile clocks). Prior to the
broadcasts of time, you had to base all navigation on local actual solar
time, calibrated to the prime meridian based on celestial observations as
best you can... Leap seconds recognized the reality that the small
variances in earth's rotation add up.

> UT1 isn't a timescale in the strictest sense. TAI and UTC are the same
> timescale, but with different second labeling. Apart from small differences
> in realtime realization, they are always lock step.  UT1 is an artificial
> construct of averaging local time as well, with the seasonal variations
> subtracted out.
>
> As per Richard Langley's note, "UT1 gives us the true orientation of the
> Earth in space as measured (now) directly by space geodetic systems.
>

Yea, I was getting UT1 and UT2 confused.

>
> We have the "smeared timescales" (Google, AWS, Bloomberg, etc). Each
>> generally varies the frequency in the 12 or 24 hours surrounding the Leap
>> Second to "hide" it from the receiving systems. This eliminates the Leap
>> Second from view, reestablishing the Gregorian calendar, and downstream
>> systems and applications behave more reliably. However, these "smears" do
>> not match each other so tractability amongst them and to UTC is
>> compromised, and the frequency shifts are more extreme than might be
>> necessary.
>>
>
> The existence and proliferation of the smears suggest, I would say, that
> leap seconds are not a good fit to a large segment of time users and
> suggests that leap seconds are a poor way to maintain synchronization.
>
> I agree. Leap Seconds have to go, and the 1/86400th of a day of the
> Gregorian calendar must be restored. This is the only feasible way for
> computer systems, applications, and traditional timekeeping systems to
> operate. However, the UTC standard with Leap Seconds cannot be
> significantly changed, as per above. So, I suggest, use DUT1 to define an
> accurate interoperable timescale that is traceable to UTC and better
> reflects the underlying phenomenon..
>
> Use of DUT1 could improve this situation. DUT1 values are announced by
>> IERS, become effective on a specific date, and typically span several weeks
>> or months periods. If the DUT1 values were used to specify a (very slight)
>> frequency shift of the dissemination clock during those intervals the
>> resulting time-points would essentially "slowly smear away" the Leap Second
>> during the entire period between announced Leap Seconds.
>>
>
> DUT1 varies a lot from day to day. It rarely spans even days when you look
> at it at enough resolution. It changes by hundreds of microseconds a day
> typically. The 100ms version that used to be included in terrestrial
> broadcasts
>
> Still is, I'm pretty sure.
>
> may have these properties, but that's a crude approximation.
>
> Ah, no, I don't think that's right, as per Richard's comment above. Look
> carefully at Bulletin D and IERS Conventions. DUT1 stays within 1/10th
> second of UTC. Its not a crude approximation.
>

DUT1 is defined to be UT1 - UTC so I don't see how you can say this.  The
Bulletin D announcements are that the announced value is rounded to the
nearest 1/10th of a second. That's an extremely crude approximation of the
value, and effectively replaces the 1s leap steps with a .1s jump when this
value changes. See column 'UT1 - UTC' in Bulletin B which varies by about
100us a day, with a mean error of about 17us. Computers really need a an
error closer to 1us to have a stable steering loop if you want to have
dissemination of something that closely approximates UT1 without steps, but
17us is likely sufficient.

> Current proposals seek to eliminate the Leap Second, decoupling
>> timekeeping from solar time, or defer the Leap Second, increasing its
>> inaccuracy. Rather than reducing the accuracies, this DUT1 driven timescale
>> idea instead *increases* the accuracies by using higher resolution than one
>> second, essentially "mini-leaps" by frequency shift. My
>> back-of-the-envelope calculations suggest the precision with respect to UTC
>> would be in the microseconds, satisfying most definitions of "legal time"
>> tolerances.
>>
>
> Most of those claimed 'legal time' tolerances haven't really been really
> well litigated.
>
> Right, not well litigated and not very clearly specified either. Financial
> regulations are helping drive definitions of "legal time". In the EU its
> defined in MiFID II as 100 microsecond. Everyone is have trouble achieving
> and verifying that.
>
> MiFID II: 10 Things You Need to Know About Time Synchronization
> http://tabbforum.com/opinions/mifid-ii-10-things-you-need-
> to-know-about-time-synchronization
>
> In the US, it's a mean solar time (error unspecified) as determined by
> some government agency, for example.
>
>
> For USA finance its currently NIST UTC time +- 50 milliseconds. See
> FINRA 6800. CONSOLIDATED AUDIT TRAIL COMPLIANCE RULE
> http://finra.complinet.com/en/display/display_viewall.html?
> rbid=2403&record_id=17601&element_id=12826&highlight=time
>

Yes and no. That's only a financial regulation for trading stocks. It isn't
controlling in other areas, but may be suggestive.

> I think the idea that the "possibility of confusing two international
>> standard time scales" is not so important. As it is there are many
>> timescales in use and it is likely they are already confused. A new
>> internationally sanctioned timescale, in addition to the existing UTC with
>> Leap Seconds, would make the physical realities of atomic time and
>> astronomical time explicit and standardized. I think having the selection
>> between two accurate international timescales would be far better than a
>> single choice that cannot possibly work. I think DUT1 could provide the raw
>> material for such a timescale and the IERS already has the information and
>> procedures in place to accomplish it.
>
>
> While an interesting idea, I think it would prove unmanageable in
> practice. But then again, we've disagreed on this point for a long time...
>
> My opinions have changed over time as I've studied this more carefully. I
> used to think UTC and Leap Seconds were cool because they neatly defined
> the atomic v.s. astronomical time, and they do. But now I think the
> approach was somewhat ill advised because it fundamentally altered the
> Gregorian calendar and that was bound to have ramifications, and it does.
>
> However, as above, I don't believe UTC can be substantially changed
> because of reverse compatibility, continuity, and installed base. So, Leap
> Seconds are here to stay, and that's good for dissemination of atomic time,
> but they must also go away if computer systems, applications, and
> traditional timekeeping systems are to operate without complication.
>
> That's where the obvious dawned on me - create a timescale more like what
> GMT once was, or was intended to be, before atomic time was invented.
> Forward into the past! DUT1 gives you the raw information to create a
> timescale that pretty closely tracks the spinning rock while remaining
> consistent with UTC and Leap Seconds. Thus, two timescales to more
> accurately represent the two physical phenomenon, atomic time and wobbly
> rock time.
>
> Note the idea is this could be implemented at the primary time servers
> where the expertise resides to accomplish it, avoiding the infeasible
> challenge of implementing some algorithm in every operating system and
> application. It would be more accurate, rather than less accurate, as other
> proposals are. I think expectation is toward better accuracy and that its
> well within modern technology to accomplish it. We just have to agree how
> to count.
>

I've seen people try to implement what they confusingly called "GMT" based
on a mistaken notion of what that term means. They would download bulletin
B from the internet and use that to construct a paper clock for UT1 from a
GPS receiver that produced UTC which they would steer their computer system
time to and then they'd run an NTP server to farm it out to their local
network. I don't know if this individual ever released this code or not.
It's possible, but problematic when you start to consider interop...

Warner

> -Brooks
>
>
> Warner
>
>
>
> _______________________________________________
> LEAPSECS mailing listLEAPSECS at leapsecond.comhttps://pairlist6.pair.net/mailman/listinfo/leapsecs
>
>
>
> _______________________________________________
> LEAPSECS mailing list
> LEAPSECS at leapsecond.com
> https://pairlist6.pair.net/mailman/listinfo/leapsecs
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pairlist6.pair.net/pipermail/leapsecs/attachments/20171023/409f0f5b/attachment.html>