On 2017-10-23 06:31 PM, Warner Losh wrote:
On Mon, Oct 23, 2017 at 3:42 PM, Brooks Harris <bro...@edlmax.com
<mailto:bro...@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@leapsecond.com <mailto:LEAPSECS@leapsecond.com>
https://pairlist6.pair.net/mailman/listinfo/leapsecs
<https://pairlist6.pair.net/mailman/listinfo/leapsecs>
_______________________________________________
LEAPSECS mailing list
LEAPSECS@leapsecond.com <mailto:LEAPSECS@leapsecond.com>
https://pairlist6.pair.net/mailman/listinfo/leapsecs
<https://pairlist6.pair.net/mailman/listinfo/leapsecs>
_______________________________________________
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs
_______________________________________________
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs
