[LEAPSECS] leap second roundup 2017
Brooks Harris
brooks at edlmax.com
Mon Oct 23 17:42:44 EDT 2017
On 2017-10-23 02:07 PM, Warner Losh wrote:
>
>
> On Mon, Oct 23, 2017 at 11:37 AM, Brooks Harris <brooks at edlmax.com
> <mailto:brooks at edlmax.com>> wrote:
>
> On 2017-10-23 09:58 AM, Rob Seaman wrote:
>
> Multiple timescales exist now for multiple purposes. Multiple
> timescales
> will exist under all scenarios. Debasing Universal Time is not a
> solution to any "real world" problem. If you want a new timescale,
> define a NEW timescale.
>
> Indeed.
>
>
> We don't need a new timescale. We have plenty.
We love timescales! Make more! :-)
> UTC has always been the best one to have. It's usefulness isn't
> because astronomers think it's great (it is inaccurate, after all, as
> a Universal Time in the astronomical sense, but it is useful enough to
> astronomers as an approximation that certain optimizations can be made
> were it not quite so accurate).
>
> To me, the frustrating thing about the discussion at ITU and
> elsewhere is the apparent outright refusal to consider a "second
> timescale". It is considered and then dismissed out of hand in:
>
> Document 7A/39-E
> United States of America
> DRAFT NEW REPORT ITU-R TF.[UTC]
> The International Time Scale, Coordinated Universal Time (UTC)
> https://www.itu.int/md/meetingdoc.asp?lang=en&parent=R15-WP7A-C&source=United%20States%20of%20America
> <https://www.itu.int/md/meetingdoc.asp?lang=en&parent=R15-WP7A-C&source=United%20States%20of%20America>
>
> In the last paragraph before the Conclusion they say
>
> "... Another alternative proposed to ensure backward compatibility
> with the current UTC time-scale is to use another international
> coordinated continuous time-scale on an equal basis. This was
> suggested as a suitable method to provide a choice of time scales
> that could be applied for a particular system. The implementation
> of such an option has not been determined as either possible or
> practical, and the possibility of confusing two international
> standard time scales makes such a solution unlikely."
>
>
> I think that is actually quite wise. What time is it really? would
> replace the "did we get the leapsecond" when different systems try to
> exchange data.
"implementation of such an option has not been determined as either
possible or practical" and that will remain true useless somebody tries.
>
> The irreconcilable difficulty arises from UTC being a modification
> of the Gregorian calendar algorithm. The world (mostly) uses
> Gregorian, but then along comes this unpredictable and irregular
> Leap Second to upset the apple cart. No clever algorithm can fit
> that 86401th second label (23:59:60) back into the Gregorian
> 86400-second-day. The Leap Second must go, and so it does, either
> by ignoring it or smearing it, thereby creating many incompatible
> and inaccurate timescales in the real world.
>
>
> Gregorian, strictly speaking, doesn't have leap seconds.
Right. 1/86400ths of an observed day. Leap Seconds throw a wrench in its
works.
> It's just a new numbering of days to keep the year alignment in sync.
> It cares not how the days are divided.
>
> There are two underlying physical phenomenon; time by atomic
> science, and time by astronomical observation. The counting
> mechanisms between the two are incommensurate because humans (and
> astronomers) expect the time-of-day to indicate the position of
> the Sun in the sky. This is not just a matter technical
> considerations but a matter of *principle*.
>
>
> True. Does time measure elapsed time, or the angle of the spinning
> rock. I posit that the latter is not interesting so long as the former
> gives an answer that's close enough (eg within an hour).
There's that value judgment again. "civil time is good enough within an
hour". The point I'm trying to make is that civil time is not a matter
of accuracy but of principle, belief, confidence, consistency with local
culture and expectations - people care about local time, not UTC, and
they take it, or would like to take it, as being perfect. They *want* it
to reflect the solar time of day.
On the other hand, in the media business I come from its not so much a
matter choice or opinion as a need to conform to local time expectations
while maintaining highly precise timing. In that application, civil time
must be accurate to at least nanoseconds to resolve media units and
maintain constant frequency while also satisfying the local time
expectations.
> Even with leap seconds, we are only forestalling the time when we must
> add them so frequently that we cannot keep up.
>
> Earlier in the same document they say:
>
> ".. Maintaining a conceptual relation with the Earth's Rotation
> Angle (represented as UT1) does not appear to be a necessity for
> the sake of civil time."
>
> Isn't that a *value judgement*? It seems its this sort of value
> judgment that upsets many who feel that solar time is important.
> At the Science of Time symposium and elsewhere we've heard many
> impassioned presentations about how important solar time is to
> humans; practically, culturally, and religiously.
>
>
> I happen to think 'uniformity of timescale' is more important than
> synchronization to a wobbly rock. But they are right: It doesn't
> matter what time the clocks say it is, so long as everybody's clock
> matches. We already accept a variance from the local solar time for
> time zones, and things like DST suggest that we as a civil society
> have a tolerance of an hour or two between observed local time and
> clock on the wall time. In this sense, civil time doesn't need to be
> tied, exactly to the second, to what the earth is doing. Society will
> function correctly if the location of the arbitrary synchronization to
> a time drifts east a little bit. We'll be good for thousands of years
> by that standard. It may be desirable for other reasons, but it isn't
> required for a civil time.
>
> Civilians *want* time to reflect astronomical time in a Gregorian
> YMDhms form. UTC with Leap Seconds has served that purpose
> admirably for decades, tying the worlds timekeeping systems
> together, albeit imperfectly. The one second accuracy compromise
> of UTC has long since been accepted as a practical matter, and the
> system has been in effect since 1972. Proposals to change it meet
> with impassioned resistance not so much on technical grounds but
> on cultural preference. "Civil time" is *supposed* to be mean
> solar time, the way its been for centuries, the way UTC has been
> since 1972, and the way the Gregorian calendar prescribes it.
>
>
> Civil time hasn't been a strict solar time for 150 years.
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.
> Not since the railroads standardized the time to be the time at an
> arbitrary location near where you are. So be careful in claiming the
> full history of time supporting Solar time. We've not been on a
> strictly solar time where I am right now system for a century and a
> half. We transitioned to a 'what time is it given my locations is
> rounded to the nearest(ish) 15 degrees.
>
> I think atomic time dissemination by UTC with Leap Seconds is
> unlikely to change because its so widely deployed, accepted since
> 1972, works great for many applications, and efforts to change it
> have failed since at least 2000. But still, somehow the Leap
> Seconds must be eliminated to reestablish compatibility with the
> unmodified Gregorian calendar.
>
>
> I tend to agree with this. However, UTC has changed several times
> since it's conception, and could easily change again with a tweak to
> the spec (though some applications might be affected). Leap Seconds
> aren't fundamental to nature, but a means to an end (finding the
> location the earth is pointing because that correlates in some way to
> human activity). It could change in the future to a timetable
> projected into the future, for example, of leap seconds. Do one every
> 18 months for the next 10 years. 5 years in, we'll publish the next
> decade's worth of data. With a change to the spec to relax DUT1, this
> could easily be *a* evolution of UTC. It's still a mean solar time
> that's non-divergent, but one whose instantaneous difference from UT1
> wanders in a larger range. This would have the benefit of
> predictability (which starts to make leap seconds testable), while
> allowing things to not wander off, just wander a bit more than they
> have been. Leap Seconds replaced a time and frequency jump schedule
> that relaxed the delta from UTC to UTC from < ~100ms to < 1s. How far
> out could we plan leaps seconds if we relaxed that further to 10s?
>
> I find it a bit incongruous that while the discussion seems to
> insist there be only one "international timescale", in fact there
> are already two (or three, if you count TAI separate from UTC, but
> UTC is the disseminated form of TAI). ITU Rec 460 defines DUT1
> (1/10th second resolution UTC-UT1), the IERS maintains and
> announces it (Bulletin D), and the radio signals broadcast it.
> This could provide the raw material on which to define a timescale
> that is more accurate than, and also traceable to, UTC.
>
>
> 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."
>
> 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.
>
> 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
>
> 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.
-Brooks
>
> Warner
>
>
>
> _______________________________________________
> 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/0990cee7/attachment-0001.html>
More information about the LEAPSECS
mailing list