[LEAPSECS] leap second roundup 2017
Brooks Harris
brooks at edlmax.com
Tue Oct 24 00:52:58 EDT 2017
On 2017-10-23 06:31 PM, Warner Losh wrote:
>
>
> On Mon, Oct 23, 2017 at 3:42 PM, Brooks Harris <brooks at edlmax.com
> <mailto: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.
Right.
>
>> 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,
Well, OK, "crude" is a bit subjective. That's what Bulletin D announces,
a value judgement made in the late 1960s that was thought to be
sufficient accuracy for celestial navigation. The IERS has higher
resolution data behind the scenes, as in Bulletin B. It could be done a
higher resolution, but I was thinking in terms of processes and data
that are available today.
> and effectively replaces the 1s leap steps with a .1s jump when this
> value changes.
Right, well, as disseminated in the radio broadcasts the UTC data
carried in the signal is constant frequency and DUT1 is the difference
(UTC-UT1) from UTC.
> 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.
Yeah, that's the idea. It would be a very slight frequency shift, I
think. But, indeed, it must be small enough for receivers to follow it
and that would need verification.
>
>> 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
> <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
> <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.
True, but this area is of particular current interest, a place where
high precision has clear impact, and where there is resources available
to work on it. Many in those arenas think 100us is not high enough, and
I'd tend to agree with that.
>
>
>
>> 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.
Yeah, you would not want to call it "GMT". As I understand the
literature, GMT was attempting to chase UT2 as it became defined (as per
Steve Allen's earlier email about those timescales), which was supposed
to provide a long-term constant frequency. Exactly what GMT as broadcast
was doing and in which era is a little unclear to me. However the idea
of a timescale driven by DUT1 is similar in the sense that it is an
approximation of observed solar time.
> 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.
Yeah, nothing is new. It would be interesting to hear what they learned
and how well it worked, if it was tried.
> It's possible, but problematic when you start to consider interop...
Well, UTC implementation is a bit problematic too. If it were well
specified I don't think its so difficult - its really not that
complicated. And keep in mind, it would only need to be implemented in
the time servers where the expertise to do it resides. Everything else
would just happily follow along.
-Brooks
>
> Warner
>
> -Brooks
>
>>
>> Warner
>>
>>
>>
>> _______________________________________________
>> LEAPSECS mailing list
>> LEAPSECS at leapsecond.com <mailto:LEAPSECS at leapsecond.com>
>> https://pairlist6.pair.net/mailman/listinfo/leapsecs <https://pairlist6.pair.net/mailman/listinfo/leapsecs>
>
>
> _______________________________________________
> LEAPSECS mailing list
> LEAPSECS at leapsecond.com <mailto:LEAPSECS at leapsecond.com>
> https://pairlist6.pair.net/mailman/listinfo/leapsecs
> <https://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/20171024/ddbce4e9/attachment-0001.html>
More information about the LEAPSECS
mailing list