subject:"Re\: \[LEAPSECS\] the big artillery"

So when I was googling around for more information about what paper
timescales the BIPM publishes, I found this:

http://iag.dgfi.badw.de/fileadmin/IAG-docs/Travaux2013/08_BIPM.pdf

which says:

 The algorithm used for the calculation of time scales is an iterative
 process that starts by producing a free atomic scale (Échelle atomique
 libre or EAL) from which TAI and UTC are derived.

 EAL is optimized in frequency stability, but nothing is done for
 matching its unit interval to the second of the International System of
 Units (SI second). In a second step, the frequency of EAL is compared to
 that of the primary frequency standards, and frequency accuracy is
 improved by applying whenever necessary a correction to the frequency of
 EAL. The resulting scale is TAI. Finally, UTC is obtained by adding an
 integral number of seconds (leap seconds). Research into time scale
 algorithms is conducted in the Time Department with the aim of improving
 the long-term stability of EAL and the accuracy of TAI /UTC

On the other hand the most frequent BIPM publication on time comparisons
is rUTC (not rTAI).

Tony.
-- 
f.anthony.n.finch  d...@dotat.at  http://dotat.at/
Rockall, Malin, Hebrides: Southeast 7 to severe gale 9 veering southwest 5 or
6. Very rough or high. Rain then showers. Moderate, occasionally poor.___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs

Re: [LEAPSECS] the big artillery

Alex Currant via LEAPSECS leapsecs@leapsecond.com wrote:

 Despite what the recommendations might say, I think the TA(k) reported
 in the Circular T are not efforts by lab K to realize TAI, since it is
 hard to imagine how a lab could get a different offset attempting to
 realize TAI from attempting to realize UTC. The values for USNO and NIST
 are extremely large, for example  The TA(k) are probably unsteered
 timescales generated by the labs for their internal use.

And for input to EAL I expect.

Tony.
-- 
f.anthony.n.finch  d...@dotat.at  http://dotat.at/
German Bight: Variable 3 or 4 becoming southeast 5 to 7. Slight or moderate,
occasionally rough later in west. Showers. Good.___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs

Re: [LEAPSECS] the big artillery

2014-11-06 Thread michael.deckers via LEAPSECS



  On 2014-11-05 15:30, Warner Losh wrote on the
  determination of TAI - UT1:


Now, back to the SI second vs the UT1 second. The UT1 second is 1E-8 or 1E-9 
different
from the SI second. Unless they are computing the results to 7 or more digits, 
the answers
will be identical, no matter which definition of second you use.


  I don't understand. Measuring (mean solar day)/(1 d) is equivalent to
  measuring d(TAI - UT1)/d(UT1); if you assume the first quantity is 1,
  then the second becomes 0. Looking at a recent Bulletin B, the uncertainty
  for measurements of the rate d(UT1)/d(TAI) is of the order 1₁₀-9 (the IERS
  give 13 digits!), and typical uncertainty for LOD is around 10 µs/d.
  The IERS certainly won't fudge on their units.

  Michael Deckers.

___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs

Re: [LEAPSECS] the big artillery

Alex Currant via LEAPSECS wrote:
Despite what the recommendations might say, I think the TA(k) reported
in the Circular T are not efforts by lab K to realize TAI,

Indeed.  TA(k) are independent time scales, apparently not steered in
either phase or frequency.  They in fact run at a variety of frequencies
relative to TAI; it looks as though several, but not all, have the
frequency of proper time at the laboratory's altitude.

The recommendation that Michael Deckers referred to does not say
otherwise.  It defines TA(k) quite distinctly from TAI(k), such that
TAI(k) is a realisation of TAI but TA(k) has essentially no constraints.

-zefram
___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs

Re: [LEAPSECS] the big artillery

michael.deckers via LEAPSECS wrote:
The IERS certainly won't fudge on their units.

I'm afraid they do.  Everyone does in this area.  Even the IAU resolutions
fudge the units.

However, Warner is *also* fudging units, in a different manner, and I
think that's causing you trouble.  Warner has said things like the UT1
second is 1e-9 different from the SI second.  That statement implies
that the UT1 second is a physical quantity, with dimensionality of
proper time, which can thus be measured using the SI second as a unit.
That's an unusual and problematic view.  Its logical conclusion is that
it's meaningless to denominate the UT1 time scale in UT1 seconds.

My view is that the UT1 second is a unit, not a variable quantity.
It's a different unit from the SI second, and can't be described in
terms of the SI second.  If anything it's a unit of angle, and so can be
described in radians or an equivalent, but it's philosophically valid
to treat it as distinct even from the angle units.  The UT1-related
quantity measurable in SI seconds, which Warner has referred to as the
UT1 second, is more accurately described as the duration of the time
period in which UT1 increments by one UT1 second, or more succinctly
the duration of the UT1 second.

There's a lot of philosophical choice about dimensionality.  Aliasing
units previously treated as distinct always leaves correct equations
still correct, and distinguishing units previously treated as two uses
of one unit can often increase clarity.  So let me acknowledge here that
it *is* also valid to alias the physical (SI) second, the angular (UT1)
second, and the pure angle equivalent, as our traditional equations do.
Aliasing the SI second to angle (as we do indirectly) isn't compatible
with SI, but then neither are Planck units.

-zefram
___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs

Re: [LEAPSECS] the big artillery

Michael Deckers via LEAPSECS wrote:
  The symbol TAI(k) is defined in
  RECOMMENDATION ITU-R TF.536-2: Time-scale notations
  of 2003 with the text:

  TAI(k): Time-scale realized by the institute k and defined
  by the relation TAI(k) = UTC(k) + DTAI,

Oh cool, same as my definition.  I didn't know about this Recommendation.
I thought this notation was natural and intuitive, as a way of referring
to this concept, and it's nice to have that supported by an independent
coinage.  Also nice to now be able to refer to a definition with higher
status than stuff wot I just thought up.

  The contributions by the various metrology institutes to TAI
  are independent from the UTC(k) and are denoted by TA(k) in
  Circular T by the BIPM.

There aren't enough TA(k) to account for all the contributions to TAI.
The TA(k) are a small group, very rarely adding new ones, and notably
lacking some of the major contributors to TAI.  There's no TA(NPL),
for example.

-zefram
___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs

Re: [LEAPSECS] the big artillery

Zefram zef...@fysh.org wrote:

 Warner has said things like the UT1 second is 1e-9 different from the
 SI second.  That statement implies that the UT1 second is a physical
 quantity, with dimensionality of proper time, which can thus be measured
 using the SI second as a unit.

The UT1 second is 2pi/86400 times the reciprocal of the angular velocity
of the Earth. The units for this quantity are just seconds (because angles
are dimensionless), or if you want to be more explicit, seconds per
2pi/86400 radians.

Tony.
-- 
f.anthony.n.finch  d...@dotat.at  http://dotat.at/
Tyne, Dogger: South 4 or 5 backing southeast 6 to gale 8. Moderate becoming
rough. Occasional rain. Moderate or good.
___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs

Re: [LEAPSECS] the big artillery

Warner Losh wrote:
On Nov 5, 2014, at 10:54 AM, Zefram zef...@fysh.org wrote:
TAI(k) = TAI + (UTC(k)-UTC) = UTC(k) + (TAI-UTC)

Except that's not how others define it.

Michael Deckers has now pointed at ITU Rec TF.536-2 which defines TAI(k)
in the same way as I do.  What conflicting definitions do you see?

Anyway, this isn't about the notation, it's about the concept.

What you should be writing is something more like TAI(UTC(x)) to denote that
you are deriving TAI form UTC(x), not that x is realizing TAI.

I wouldn't object to using such notation.  However, I reject the claim
that this doesn't amount to x realising TAI.

In the rest of your message, I'm not clear whether your uses of TAI(x)
refer to the concept I was talking about or something else.  If it's
something else, I'm mystified as to what, but then we'd be talking at
cross purposes whatever it was.  To be clear, I'm talking about the thing
that I called TAI(x), that is the TAI realisation implied by UTC(x), not
anything else that someone might have given the same name.  My argument
would certainly not apply with any other concept substituted there.

  FOO(x) is the FOO timescale as realized by x. You have to
have actual clocks or oscillators ticking the signals out. To while UTC(x) 
exists for
a large number of x, TAI(x) doesn't.

How does TAI(x) not exist?  I have explained how the time signals that
deliver UTC(x) serve equally to deliver TAI(x).  Are you claiming that
the TAI(x) doesn't count merely because the time signal supplier doesn't
*intend* the signal to provide TAI(x) per se?  That would be a poor
reason to reject the validity of TAI(x), given that TAI(x) is directly
implied by UTC(x).  Or perhaps you claim it doesn't count because the
signal doesn't fully encode TAI(x) in-band?  But as I explained, MSF
doesn't fully encode UTC(NPL) in-band either.

 You can find the corresponding TAI time 
 for any
x's UTC(x) after the fact when  BIPM publishes the data.

Red herring.  I'm not saying you get canonical TAI in real time;
that's impossible.  You equally can't get canonical UTC in real time.
What you get in real time is TAI(x), along with UTC(x).  These are pretty
good approximations of canonical TAI and canonical UTC respectively.

-zefram
___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs

Re: [LEAPSECS] the big artillery

2014-11-06 Thread Steffen Nurpmeso

Bonjour,

Michael Deckers via LEAPSECS leapsecs@leapsecond.com wrote:
 |On 2014-11-05 11:28, Steffen Nurpmeso wrote:
 | Oh, the German Physikalisch-Technische Bundesanstalt (PTB) also
 | has a general -- at least -- overview of the set of problems.
 | (English: [1] and all around that; oops, not everything is
 | translated, what a shame!  I hope it's not due to lack of
 | resources, which seems to become notorious in Germany [for things
 | that really matter at least].)
 | ..
 |[1] https://www.ptb.de/cms/en/fachabteilungen/abt4/f\
 |b-44/ag-441/realisation-of-the-si-second.html
 |Rest under
 |https://www.ptb.de/cms/en/fachabteilungen/abt4/fb-44\
 |/ag-441/realisation-of-legal-time-in-germany/

 |   The very beginning of the last reference is misleading and

..coordinated-universal-time-utc.html

 |   wrong:
 |
 |  Properties of UTC
 |
 |   The time scale UTC (Coordinated Universal Time) owes its
 |   existence to the CCIR (International Consultative Committee
 |   of Radiocommunications) of the ITU (International
 |   Telecommunications Union) which proposed to broadcast
 |   time signals worldwide in a coordinated way, i.e.
 |   by reference to a common time scale.
 |
 |   The concept for UTC was devised by people from the BIH
 |   and some other metrology institutes, not by the CCIR;
 |   and the CCIR has never produced a time scale. It is
 |   unfortunate that most sources about time and time scales
 |   are full of inaccuracies and errors like these, perpetuated
 |   through hundreds of papers and books.

Hm, indeed a sloppy translation of the original german text

  Die Einführung der Zeitskala UTC geht auf Vorschläge des CCIR
  (Comité Consultatif International des Radiocommunications)
  zurück

which is more like Introduction of the time scale UTC originates
in suggestions made by...  And isn't that in line with Steve
Allen's sleuthing, which ends up saying

  Recommendation 374 contained the details of what is now
  informally referred to as the original form of UTC even though
  the CCIR did not use that name.

But of course passion can't be replaced by anything else.
Maybe money?

--steffen
___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs

Re: [LEAPSECS] the big artillery

2014-11-06 Thread Sanjeev Gupta

On Thu, Nov 6, 2014 at 8:38 PM, Tony Finch d...@dotat.at wrote:

 The UT1 second is 2pi/86400 times the reciprocal of the angular velocity
 of the Earth. The units for this quantity are just seconds (because angles
 are dimensionless), or if you want to be more explicit, seconds per
 2pi/86400 radians.


... which I think is the clearest definition I have heard so far.

Note that seconds are also a unit of angles, so UT1 seconds being a
measure of angle is not strange.

Thank you, Tony.
-- 
Sanjeev Gupta
+65 98551208 http://www.linkedin.com/in/ghane
___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs

Re: [LEAPSECS] the big artillery

2014-11-06 Thread Poul-Henning Kamp


In message CAHZk5WfKSLMy77HK1Vsvk9PQ5v=tpb0rzuri8j4kmcezooa...@mail.gmail.com
, Sanjeev Gupta writes:

Note that seconds are also a unit of angles, so UT1 seconds being a
measure of angle is not strange.

...and I'm sure any surveyor or ships navigator would be extremely suprised
if somebody told him that the degree between 23°59' and 24°00' had
sixtyone seconds once every other year or so.

minutes and seconds are fractions of 60 and have been so since
babylonian times for minutes and since 13-mumble for seconds.

-- 
Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer   | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs

Re: [LEAPSECS] the big artillery


On Nov 5, 2014, at 7:57 PM, Alex Currant via LEAPSECS leapsecs@leapsecond.com 
wrote:

 Despite what the recommendations might say, I think the TA(k) reported in the 
 Circular T are not efforts by lab K to realize TAI, since it is hard to 
 imagine how a lab could get a different offset attempting to realize TAI from 
 attempting to realize UTC. The values for USNO and NIST are extremely large, 
 for example  The TA(k) are probably unsteered timescales generated by the 
 labs for their internal use.

That’s definitely the case. They are their own internal time scales that are 
usually not steered. Steering introduces complication into knowing what to do 
with the error terms, so most of the time systems I’ve seen usually have an 
un-steered component that is measured against the signal that you want to 
generate to steer that signal. TA(k) isn’t implied to be TAI anything anywhere 
in the recommendations that I could see.

Warner

 On the other hand, maybe that whole section of the Circular T is just a 
 vestigial contribution from a bygone era.Those who needed to interface 
 with civil time used UTC, and it seems those who needed a continuous 
 timescale did whatever seemed easiest at the time.   Today, those who need a 
 continuous timescale to interface with civil time, or who don't know what 
 they are doing, can always be pleasantly surprised by a chance to earn 
 overtime at New Year's or on July 1.
  
 
 
 
 
 From: Michael Deckers via LEAPSECS leapsecs@leapsecond.com
 To: Leap Second Discussion List leapsecs@leapsecond.com 
 Sent: Wednesday, November 5, 2014 3:59 PM
 Subject: Re: [LEAPSECS] the big artillery
 
 
 On 2014-11-05 16:27, Zefram wrote:
 
  ...  UTC is always
  an integral number of seconds offset from TAI, and so by construction
  UTC(NPL) is always an integral number of seconds offset from TAI(NPL).
  Hence each of the marks also occurs at the top of a second of TAI(NPL).
 
   The symbol TAI(k) is defined in
   RECOMMENDATION ITU-R TF.536-2: Time-scale notations
   of 2003 with the text:
 
   TAI(k): Time-scale realized by the institute “k” and defined
   by the relation TAI(k) = UTC(k) + DTAI, where DTAI
   is the number of integral seconds specified by the
   International Earth Rotation Service (IERS) as
   being the difference between UTC and TAI;
 
   I do not know whether that notation has ever been put
   to serious use outside this recommendation.
 
   The contributions by the various metrology institutes to TAI
   are independent from the UTC(k) and are denoted by TA(k) in
   Circular T by the BIPM. The recommendation explains it as:
 
   TA(k): Atomic Time-scale, as realized by the institute “k”;
 
   Michael Deckers.
 
 ___
 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



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs

Re: [LEAPSECS] the big artillery


On Nov 6, 2014, at 4:40 AM, michael.deckers via LEAPSECS 
leapsecs@leapsecond.com wrote:

 
  On 2014-11-05 15:30, Warner Losh wrote on the
  determination of TAI - UT1:
 
 Now, back to the SI second vs the UT1 second. The UT1 second is 1E-8 or 1E-9 
 different
 from the SI second. Unless they are computing the results to 7 or more 
 digits, the answers
 will be identical, no matter which definition of second you use.
 
  I don't understand. Measuring (mean solar day)/(1 d) is equivalent to
  measuring d(TAI - UT1)/d(UT1); if you assume the first quantity is 1,
  then the second becomes 0. Looking at a recent Bulletin B, the uncertainty
  for measurements of the rate d(UT1)/d(TAI) is of the order 1₁₀-9 (the IERS
  give 13 digits!), and typical uncertainty for LOD is around 10 µs/d.
  The IERS certainly won't fudge on their units.

I’m not assuming the first quantity is 1. I’m saying that when you need a 
low-precision answer
the calculation is simple. Way 1 I describe below. When you need higher 
precision, you
need to do the complicated thing I described before and summarize below. Way 1 
below is
different than assuming they are the same, it just assumes that a delta time in 
the arrival
of PPS pulses is sufficient to make a statement about the phase difference in 
seconds.

There are two ways to obtain numbers for a difference in time scales. One is to 
have
each one produce a PPS. Then a time interval counter can easily measure the 
differences
in PPS. That’s one definition of phase difference. For the UT1 case, you steer 
an atomic
clock or other device that can create a PPS to celestial observations and you 
compare
that PPS to the PPS of a clock that’s steered to UTC with a TIC. TICs can do 
remote
data collection, but that’s a pain and likely not what’s done. Especially since 
the data for
UT1 doesn’t come from some reference oscillator, but from celestial 
observations and
transit times.

Way two is to convert the measurements to cycles or some other measure of the 
angle
of the phase. You can then subtract the angle / cycle of the phase from each 
other after
interpolating them to a common time. Once you have  a phase difference in 
cycles / radians,
you can convert that to a time difference using whatever definition of the 
‘second’ that
is appropriate. For UT1, this almost has to be the way things are computed since
you have a bunch of points in time that correspond to celestial events which 
are then
translated to an angular position / UT1 time which can be correlated to UTC 
which gives
you the phase and frequency evolution of UT1 relative to UTC.

Warner


signature.asc
Description: Message signed with OpenPGP using GPGMail
___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs

Re: [LEAPSECS] the big artillery


On Nov 6, 2014, at 5:09 AM, Zefram zef...@fysh.org wrote:
 My view is that the UT1 second is a unit, not a variable quantity.
 It's a different unit from the SI second, and can't be described in
 terms of the SI second.  If anything it's a unit of angle, and so can be
 described in radians or an equivalent, but it's philosophically valid
 to treat it as distinct even from the angle units.  The UT1-related
 quantity measurable in SI seconds, which Warner has referred to as the
 UT1 second, is more accurately described as the duration of the time
 period in which UT1 increments by one UT1 second, or more succinctly
 the duration of the UT1 second.

You are correct. The UT1 second” is a measure of angular motion of
the earth, averaged in a particular way. When I say that it is different
than the SI second by 1e-9 or so, you’re right about what I really mean:
“The typical duration of the time it takes for the earth to rotate a UT1
second differs from the SI second a bit, usually on the order of 1e-9 or so”
but even that’s not quite right since the UT1 second is an average
of a bunch of actual earth rotation seconds to smooth out certain
well known wobbles.

The conversion of the signals to a phase within a cycle, and talking
about differences in phase angles is designed to give a common set
of units. Note this phase angle isn’t measuring the phase angle of the
earth, but rather converting a PPS signal or number to a sine wave
and comparing that. For high frequencies, where you’re trying to find
the difference in frequency between two 5MHz or 1GHz oscillators,
talking about the phase angle difference makes a lot more sense
because it isn’t as artificial a construct. And when comparing atomic
clocks to each other, you almost never use the PPS to make the
comparison, but do measurements and transformations on the high
frequency outputs to measure the difference.

I’ve gotten so used to thinking of things in the short hand terms that
I’d forgotten that I was even using them.

Warner


signature.asc
Description: Message signed with OpenPGP using GPGMail
___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs

Re: [LEAPSECS] the big artillery


On Nov 6, 2014, at 5:55 AM, Zefram zef...@fysh.org wrote:

 Warner Losh wrote:
 On Nov 5, 2014, at 10:54 AM, Zefram zef...@fysh.org wrote:
   TAI(k) = TAI + (UTC(k)-UTC) = UTC(k) + (TAI-UTC)
 
 Except that's not how others define it.
 
 Michael Deckers has now pointed at ITU Rec TF.536-2 which defines TAI(k)
 in the same way as I do.  What conflicting definitions do you see?

The recommendation has been withdrawn. The conflicting definitions I’ve seen
have been from one of the time scientists that helped to setup TAI when he was
at NBS(later NIST) who strenuously instructed me that they weren’t equivalent 
and
was quite patient with my stupid questions about “why not. I did this research
about 10 years ago now, so I don’t have pointers to the original sources. Most 
likely
it was on the English pages of the BIPM’s web site in the 2003 or 2004 time
frame. Not ideal, I know.

 Anyway, this isn't about the notation, it's about the concept.

The concept I’d agree with you. But without a realization of the time scale, it
doesn’t actually exist. I know that I’m being picky here about the difference
between realizing TAI directly and deriving it from some realization of UTC.
And for most uses, I’d totally agree that the answers you get from doing this
will be the same. But if you zoom in far enough, you’ll see there’s a lot more
chaos than that going on, and that TAI and UTC(k) aren’t quite the same thing
when you get to the nanosecond level or beyond. TAI and UTC are, but nobody
has UTC, they only have UTC(x). The folks from BIPM are worried that if people
are talking about TAI time, and measurements against it, confusion will result 
in
the atomic time clock time scale community about what the measurements really
mean.

As a practical matter, I don’t see the problem with people using the TAI 
numbering
of seconds. Or even using the informal definitions of “The TAI time I got from 
UTC.”
But to the folks that set up this system, such a suggestion is rings in their 
ears like
‘you could just pound the screws in with a hammer’. Most of the time that works
well enough, for a while, but it isn’t quite the right thing to do. But since 
they control
the recommendations, to a degree, they get to make the rules.

Warner


signature.asc
Description: Message signed with OpenPGP using GPGMail
___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs

Re: [LEAPSECS] the big artillery

Poul-Henning Kamp p...@phk.freebsd.dk wrote:

 minutes and seconds are fractions of 60 and have been so since
 babylonian times for minutes and since 13-mumble for seconds.

The etymology is actually helpful in this case rather than misleading as
etymologies so often are.

minute is short for pars minuta prima, the first small part
second is short for pars minuta secunda, the second small part

a small part being a 1/60th fraction of whatever big thing we are
counting, hours of time or degrees or arc or whatever.

Tony.
-- 
f.anthony.n.finch  d...@dotat.at  http://dotat.at/
Southeast Iceland: Southeasterly, becoming cyclonic, 7 to severe gale 9, then
becoming southerly 4 or 5. Very rough becoming rough. Occasional rain.
Moderate, occasionally poor.
___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs

Re: [LEAPSECS] the big artillery

2014-11-06 Thread Sanjeev Gupta

On Thu, Nov 6, 2014 at 10:37 PM, Poul-Henning Kamp p...@phk.freebsd.dk
wrote:


 In message CAHZk5WfKSLMy77HK1Vsvk9PQ5v=
 tpb0rzuri8j4kmcezooa...@mail.gmail.com
 , Sanjeev Gupta writes:

 Note that seconds are also a unit of angles, so UT1 seconds being a
 measure of angle is not strange.

 ...and I'm sure any surveyor or ships navigator would be extremely suprised
 if somebody told him that the degree between 23°59' and 24°00' had
 sixtyone seconds once every other year or so.


To a person (me) who last used a theodolite in 1988, very surprising.  But
I assume that to a professional navigator, this would be just another
correction he makes.

After all, (an inexact analogy), every year has 365 days, but sometimes we
slip in aa extra between 28 Feb and 01 Mar.   Every fourth year.  Except
when we don't.  We are lucky that 2000 was a leap year, so people who did
not know the 100  and 400 year rules got it right by mistake.

(back to Leapsecs)
The difference, I suppose, and the point where I agree with you, is that we
_know_ when the next leap year will happen, but Dr Gambis gives us shorter,
and essentially surprising, notice on the leap minute.  Removing leap
seconds is OK with me, the fact that the earth angle will lose sync with
civil time is a small price for 7 billion of us, and I willing to throw
astronomers to the wolves.  (What have the Romans ever done for us, anyway?)

The point where I disagree with you is keeping the name UTC.  When we
(and I use the term loosely) changed the rule from leap every fourth year
to (except for 100th year, except for 400th year). the new calendar had a
new name.  Over time we stopped using Julian, but if I was to tell you 13
Jan 1300 Julian, you would know if it was a leap year or not.  I believe
the USA'ns make a big deal of George Washington's birthday being OS/NS,
etc; but we can get the joke only because there are suffixes that tell me
what scale it is.

Look at this thread, and the efforts being made by you et al to remove the
confusion about the word second; because the SI second, the TAI (term
used without prior permission of BIPM) second, and the UT1 second. all use
the word second.

-- 
Sanjeev Gupta
+65 98551208 http://www.linkedin.com/in/ghane
___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs

Re: [LEAPSECS] the big artillery

Warner Losh wrote:
   The conflicting definitions I've seen
have been from one of the time scientists that helped to setup TAI when he was
at NBS(later NIST) who strenuously instructed me that they weren't equivalent 
and
was quite patient with my stupid questions about why not.

Intriguing.  I'd really like to learn more about this.

 Anyway, this isn't about the notation, it's about the concept.

The concept I'd agree with you. But without a realization of the time scale, it
doesn't actually exist.

My claim is that UTC(k)+DTAI (which I've been referring to as TAI(k))
*is* a realisation of TAI.  It's available in real time: as available
as UTC(k) is, in contexts where DTAI is readily available.  Its accuracy
and other qualities are traceable to k, and are by construction identical
to those qualities of UTC(k).

I know that I'm being picky here about the difference
between realizing TAI directly and deriving it from some realization of UTC.

I don't see what difference you're basing this distinction on.
The realisations of UTC and TAI seem equally direct.

  But if you zoom in far enough, you'll see there's a lot more
chaos than that going on, and that TAI and UTC(k) aren't quite the same thing
when you get to the nanosecond level or beyond.

Red herring.  Once again, you're bringing in the nanosecond-level
UTC(k)-UTC difference as if it's a difference between TAI and UTC.
I never claimed that canonical TAI was available in real time; I never
claimed an equivalence between UTC(k) and TAI.  The nanosecond-level
tracking error UTC(k)-UTC needs to be considered, if nanosecond precision
matters, regardless of whether you're using TAI or UTC at the seconds
level.

-zefram
___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs

Re: [LEAPSECS] the big artillery

2014-11-06 Thread Clive D.W. Feather

Tony Finch said:
 minutes and seconds are fractions of 60 and have been so since
 babylonian times for minutes and since 13-mumble for seconds.
 
 The etymology is actually helpful in this case rather than misleading as
 etymologies so often are.
 
 minute is short for pars minuta prima, the first small part
 second is short for pars minuta secunda, the second small part

And I've seen third and fourth, with the obvious meaning, used in old
documents.

But etymology doesn't override present meanings.

-- 
Clive D.W. Feather  | If you lie to the compiler,
Email: cl...@davros.org | it will get its revenge.
Web: http://www.davros.org  |   - Henry Spencer
Mobile: +44 7973 377646
___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs

Re: [LEAPSECS] the big artillery

2014-11-06 Thread Gerard Ashton

If you want to go all the way back, Sumerian clay tablets arranged numbers
in a grid that looked a lot like a modern spreadsheet, and one unit in a
given column was equivalent to 60 units in the column immediately to the
right.

-Original Message-
From: LEAPSECS [mailto:leapsecs-boun...@leapsecond.com] On Behalf Of Clive
D.W. Feather
Sent: Thursday, November 6, 2014 11:20 AM
To: Leap Second Discussion List
Subject: Re: [LEAPSECS] the big artillery

Tony Finch said:
 minutes and seconds are fractions of 60 and have been so since 
 babylonian times for minutes and since 13-mumble for seconds.

 The etymology is actually helpful in this case rather than misleading 
 as etymologies so often are.

 minute is short for pars minuta prima, the first small part 
 second is short for pars minuta secunda, the second small part

And I've seen third and fourth, with the obvious meaning, used in old
documents.

But etymology doesn't override present meanings.

-- 
Clive D.W. Feather  | If you lie to the compiler,
Email: cl...@davros.org | it will get its revenge.
Web: http://www.davros.org  |   - Henry Spencer
Mobile: +44 7973 377646
___
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

Re: [LEAPSECS] the big artillery


On Nov 6, 2014, at 11:24 AM, Dennis Ferguson dennis.c.fergu...@gmail.com 
wrote:

 
 On Nov 6, 2014, at 11:19, Clive D.W. Feather cl...@davros.org wrote:
 
 Tony Finch said:
 minutes and seconds are fractions of 60 and have been so since
 babylonian times for minutes and since 13-mumble for seconds.
 
 The etymology is actually helpful in this case rather than misleading as
 etymologies so often are.
 
 minute is short for pars minuta prima, the first small part
 second is short for pars minuta secunda, the second small part
 
 And I've seen third and fourth, with the obvious meaning, used in old
 documents.
 
 But etymology doesn't override present meanings.
 
 It isn't really a question of what present meanings are, but of whether they 
 are
 a good idea or not.  If the hectosecond were redefined to sometimes be 99 or 
 101
 seconds, with a table lookup required to find out which kind you were in, I 
 wouldn't
 think that was a good idea even if it did fix a problem someone was having.
 
 In some ways the UTC minute redefinition is even worse than that.  A 6 year 
 old
 might not know how many seconds are in a hectosecond but would often be
 expected to know there are 60 seconds in a minute.  Redefining this to be 
 otherwise
 seems bound to cause cognitive dissonance in many grown up former 6 year olds.

As smart as computers are, they are less smart and less flexible than 6 year 
olds.

Warner


signature.asc
Description: Message signed with OpenPGP using GPGMail
___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs

Re: [LEAPSECS] the big artillery

2014-11-06 Thread Michael Deckers via LEAPSECS



   On 2014-11-06 13:10, Steffen Nurpmeso wrote

   in defense of the description by the German metrology
   laboratory in [https://www.ptb.de/cms/en/fachabteilungen
   /abt4/fb-44/ag-441/coordinated-universal-time-utc.html]:


Hm, indeed a sloppy translation of the original German text

   Die Einführung der Zeitskala UTC geht auf Vorschläge des CCIR
   (Comité Consultatif International des Radiocommunications)
   zurück

which is more like Introduction of the time scale UTC originates
in suggestions made by...


  But the German text is equally wrong.

  The CCIR was tasked to find a common time scale for
  radio dissemination, but they did not suggest the
  underlying concepts of UTC. The concepts were developed
  about 1960 within the RGO, NPL, USNO and the BIH, at a
  time when time determination meant the reduction of
  UT0 to UT1, and a common reference time scale with
  rate close to UT2 was an enormous help.


But of course passion can't be replaced by anything else.
Maybe money?


  I do not see which point you want to make here.

  Michael Deckers.

___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs

Re: [LEAPSECS] the big artillery

2014-11-06 Thread Michael Deckers via LEAPSECS



  On 2014-11-04 22:26, Steve Allen quoted Bernard Guinot
  about the unit for the difference TAI - UT1:


Guinot explained this using the term graduation second
in section 2.2 of 1995 Metrologia 31 431
http://iopscience.iop.org/0026-1394/31/6/002

He points out that the way the IAU has written the definitions of the
time scales uses a subtly ambiguous notation.  He writes

   The numerical value of UT1(IERS)-TAI does not
   of course, express a duration. In this context, the s
   only conveys the information that the readings of the
   two time scales are expressed in graduation seconds.


  Guinot comes back to this question, and revises his position,
  in [Guinot 2011, section 7.a, p 4139], where he exposes the
  underlying fundamental question: how can the set of spacelike
  and timelike coordinates be given consistent dimensions
  (invariant under the Minkowski group). He writes:

 (a) Unit of relativistic coordinates

 Some authors consider the relativistic coordinates as dimensionless,
 others give a special name to their unit, such as the ‘TCB second’ or
 a global name such as ‘graduation unit’. I was myself
 in favour of the latter name. However, after long discussions with
 eminent metrologists, Quinn and de Boer, I agreed that it was
 simpler to name ‘second’ the graduation unit. Thus, more generally,
 all quantities having the dimension of time have the second (without
 any qualifier) as their unit, even if they have different natures,
 such as time interval and reading of a time scale. If the logic of
 this point of view seems rather obscure, then it is possible to
 consider it as a convention which has the merit of being in
 agreement with the quantity calculus. It also agrees with the
 metrological rule that the unit does not define a quantity.

   While I can only agree with Guinot's position, I am not sure whether
   space coordinates and relativistic change of coordinates can be modeled
   neatly in that way. Amazing that simple questions about time scales
   can lead to such really fundamental conceptual issues!

   Reference:
[Guinot 2011] Bernard Guinot: Time scales in the context of general
   relativity. in: Philosophical Transactions of the Royal Society A.
   vol 369 p 4131..4142. 2011-09-19. online at:
   [rsta.royalsocietypublishing.org/content/369/1953/4131.full.pdf]

   Michael Deckers.

___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs

Re: [LEAPSECS] the big artillery

2014-11-06 Thread Alex Currant via LEAPSECS

I don't think it is correct to say that astronomers are being thrown to the 
wolves.  The IAU has not taken a stand on this - if it were so simple then the 
disagreements that were expressed in the IAU deliberations would not have been 
sufficient to prevent a resolution.  It is true that some estimates of large 
conversion expenses have been presented, but others consider such claims 
ridiculously large for a number of reasons that are not part of this thread.

  From: Sanjeev Gupta gha...@gmail.com
 To: Poul-Henning Kamp p...@phk.freebsd.dk 
Cc: Leap Second Discussion List leapsecs@leapsecond.com 
 Sent: Thursday, November 6, 2014 11:17 AM
 Subject: Re: [LEAPSECS] the big artillery

On Thu, Nov 6, 2014 at 10:37 PM, Poul-Henning Kamp p...@phk.freebsd.dk wrote:

In message CAHZk5WfKSLMy77HK1Vsvk9PQ5v=tpb0rzuri8j4kmcezooa...@mail.gmail.com
, Sanjeev Gupta writes:

Note that seconds are also a unit of angles, so UT1 seconds being a
measure of angle is not strange.

...and I'm sure any surveyor or ships navigator would be extremely suprised
if somebody told him that the degree between 23°59' and 24°00' had
sixtyone seconds once every other year or so.

To a person (me) who last used a theodolite in 1988, very surprising.  But I 
assume that to a professional navigator, this would be just another correction 
he makes.

After all, (an inexact analogy), every year has 365 days, but sometimes we slip 
in aa extra between 28 Feb and 01 Mar.   Every fourth year.  Except when we 
don't.  We are lucky that 2000 was a leap year, so people who did not know the 
100  and 400 year rules got it right by mistake.

(back to Leapsecs)
The difference, I suppose, and the point where I agree with you, is that we 
_know_ when the next leap year will happen, but Dr Gambis gives us shorter, and 
essentially surprising, notice on the leap minute.  Removing leap seconds is OK 
with me, the fact that the earth angle will lose sync with civil time is a 
small price for 7 billion of us, and I willing to throw astronomers to the 
wolves.  (What have the Romans ever done for us, anyway?)

The point where I disagree with you is keeping the name UTC.  When we (and I 
use the term loosely) changed the rule from leap every fourth year to (except 
for 100th year, except for 400th year). the new calendar had a new name.  Over 
time we stopped using Julian, but if I was to tell you 13 Jan 1300 Julian, you 
would know if it was a leap year or not.  I believe the USA'ns make a big deal 
of George Washington's birthday being OS/NS, etc; but we can get the joke only 
because there are suffixes that tell me what scale it is.

Look at this thread, and the efforts being made by you et al to remove the 
confusion about the word second; because the SI second, the TAI (term used 
without prior permission of BIPM) second, and the UT1 second. all use the word 
second.  

-- 
Sanjeev Gupta
+65 98551208     http://www.linkedin.com/in/ghane
___
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

Re: [LEAPSECS] the big artillery

2014-11-06 Thread Sanjeev Gupta

On Fri, Nov 7, 2014 at 2:24 AM, Dennis Ferguson dennis.c.fergu...@gmail.com
 wrote:

 In some ways the UTC minute redefinition is even worse than that.  A 6
 year old
 might not know how many seconds are in a hectosecond but would often be
 expected to know there are 60 seconds in a minute.  Redefining this to be
 otherwise
 seems bound to cause cognitive dissonance in many grown up former 6 year
 olds.


A six-year old can continue to believe that a minute has 60 seconds, and an
year has 365 days, and a mile is 1 and a half km.

When Rob Seaman decides to allow said six-year old near his telescope, he
can teach the extra rules.  But do not *define* the year to be 365 days.

As a general rant, I still complain that (roughly) year 8 to year 12 of my
schooling required me to learn stuff in physics, and then the next year,
often the same teacher would tell me what I had learnt was wrong, and this
was the correct way.  We teach Newtonian mechanics in high school, and then
a year or two later, *the same guy*, smirking, tells you that actually,
that is wrong, a simplification for children.

But we still teach and respect the Lorentz corrections, even though we all
know that momentum is mass times velocity.

Anyone who wishes to believe 60 secs always to a minute can continue to do
so.  Anyone who needs the extra accuracy (time-nuts, astronomers, pedants,
old men like me) will learn the fact that a minute is not always 60 secs.
Anyone who is unwilling to learn this should not be pointing the scope on
Mt Palomar anyway.

-- 
Sanjeev Gupta
+65 98551208 http://www.linkedin.com/in/ghane
___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs

Re: [LEAPSECS] the big artillery

2014-11-05 Thread Zefram

Brooks Harris wrote:
On 2014-11-04 04:59 PM, Zefram wrote:
(Contrary to Brooks's earlier statement, the table does not
imply anything about pre-1972 UTC.)
I don't understand why you say that. Can you explain what you mean?
It seems to me the origins of both PTP and NTP are certainly
pre-1972 UTC.

The PTP epoch is not defined by UTC.  Expressing the PTP epoch in UTC,
as is done in clause 7.2.2, does require specific knowledge of pre-1972
UTC, and clause 7.2.2 thus clearly implies that pre-1972 UTC is the
rubber-seconds system described by tai-utc.dat.  But table B.1 doesn't
express the PTP epoch in UTC.

The NTP epoch is notionally in UTC, but as previously noted the historical
leap schedule doesn't affect current NTP-UTC conversions.  The NTP
system thus doesn't imply any particular leap schedule.  It is agnostic
on pre-1972 UTC behaviour, in fact to the extent that it's no problem
at all that the NTP epoch precedes by decades not only all forms of UTC
but even atomic clocks.  Table B.1 doesn't attempt to express the NTP
epoch in TAI, or do anything else that would break this agnosticism.

Table B.1 doesn't give any specific conversions between NTP and PTP
scalar values, nor between those and UTC or TAI.  In particular, it
doesn't give any conversion for the NTP epoch.  So no implied UTC leap
schedule here.  What it does give is a pair of complementary conversion
formulae, amounting to

PTP_scalar = NTP_scalar - 2208988800 + currentUtcOffset

This allows us to compute specific conversions for any time for
which all these terms are well defined.  The critical part is that
currentUtcOffset, which refers to the difference (TAI-UTC)/s.
In order to perform a conversion, you have to supply the correct
DTAI value yourself; the conversion formulae do not tell you the DTAI
value.  In order to be able to perform a conversion, there has to be a
well-defined DTAI value; the conversion formulae do not imply that there
always is one.  The formulae thus do not imply any specific leap schedule,
nor any specific extent of UTC.

From 1972 onwards, DTAI is uncontroversial.  From 1961 to 1971, it is
possible to use the conversion formula with the rubber-seconds UTC, with
the understanding that currentUtcOffset will usually be fractional (as
it is in the time_t example in section B.2).  However, it's rather silly
to perform a conversion for that era, because neither PTP nor NTP existed
back then, and both protocols by nature only process current timestamps.
Prior to 1961, DTAI is undefined because UTC is undefined, so it is not
possible to perform a PTP-NTP conversion with respect to real UTC.

If you decide to instead use a fictitious version of UTC and TAI for
pre-1972 times, you may have a well-defined fictitious DTAI as far
back as you like.  This may match rubber-seconds UTC over its era or
differ from it; it may have whatever leap schedule and frequency shifts
you like.  Under such a system, you can use the same conversion formula
to perform well-defined, but entirely fictitious, PTP-NTP conversions.
As with conversions using the real rubber seconds, this is silly due to
the protocols not having been in use at the time.

The conversion formulae in table B.1 don't tell you the UTC leap schedule.
They're a framework that makes use of whatever leap schedule you choose
to feed into them.

-zefram
___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs

Re: [LEAPSECS] the big artillery

2014-11-05 Thread Tony Finch

Gerard Ashton ashto...@comcast.net wrote:

 For example, the Standards of Fundamental Astronomy subroutine iauDat
 provides the delta between TAI and UTC, and the source code comments say
 UTC began at 1960 January 1.0 (JD 2436934.5) and it is improper to call
 the function with an earlier date. In as much as UTC attempted to track
 UT2 in the 1960s, I would regard 1960 January 1.0 as the dividing point
 between proleptic UTC and UTC, and I would regard proleptic UTC as
 synonymous with UT2.

Does anyone know where SOFA iauDat got its data for 1960 from? Because
that predates the USNO table.

Tony.
-- 
f.anthony.n.finch  d...@dotat.at  http://dotat.at/
Plymouth, Biscay: Northwesterly 5 to 7 decreasing 4, then backing
southwesterly 5 or 6 later in Plymouth and northwest Biscay. Moderate or rough
becoming slight or moderate. Showers, thundery at first. Good, occasionally
moderate at first.
___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs

Re: [LEAPSECS] the big artillery

2014-11-05 Thread Steffen Nurpmeso

Michael Deckers via LEAPSECS leapsecs@leapsecond.com wrote:
 |   On 2014-11-04 19:45, Brooks Harris wrote on the history of UTC:
 |
 | For purposes of astronomy, and probably others, the rubber \
 | band era may have
 | relevance. To call it UTC seems a bit of a stretch to me, but there's no
 | generally accepted name for what Zefram calls rubber-seconds era of UTC.
 |
 |   An excellent account of the political and technical history of UTC is on
 |   Steve Allen's page [http://www.ucolick.org/~sla/leapsec\
 |   s/timescales.html#UTC].

Oh, the german Physikalisch-Technische Bundesanstalt (PTB) also
has a general -- at least -- overview of the set of problems.
(English: [1] and all around that; oops, not everything is
translated, what a shame!  I hope it's not due to lack of
resources, which seems to become notorious in Germany [for things
that really matter at least].)

Those ladies and gentlemen also seem to have the ambition to
reduce the non-realtimity [2]:

  In the year 2013, 25 time scales UTC(k) with deviations
  UTC-UTC(k) of less than 10 ns existed. For example, the
  difference UTC-UTC(PTB) was 0,8 ns on January 2, 2013.

  [1] 
https://www.ptb.de/cms/en/fachabteilungen/abt4/fb-44/ag-441/realisation-of-the-si-second.html
  Rest under
  
https://www.ptb.de/cms/en/fachabteilungen/abt4/fb-44/ag-441/realisation-of-legal-time-in-germany/
  [2] ...coordinated-universal-time-utc.html
  [3] ...atomic-time-scales.html
  [4] ...the-time-scales-tai-and-eal.html
  [5] ...leap-seconds.html

--steffen
___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs

Re: [LEAPSECS] the big artillery

2014-11-05 Thread Steve Allen

On Wed 2014-11-05T11:11:38 +, Tony Finch hath writ:
 Does anyone know where SOFA iauDat got its data for 1960 from? Because
 that predates the USNO table.

By the way, which USNO table is that?
I'm wondering if it is actually a reprint of the BIH table.

--
Steve Allen s...@ucolick.orgWGS-84 (GPS)
UCO/Lick Observatory--ISB   Natural Sciences II, Room 165Lat  +36.99855
1156 High StreetVoice: +1 831 459 3046   Lng -122.06015
Santa Cruz, CA 95064http://www.ucolick.org/~sla/ Hgt +250 m
___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs

Re: [LEAPSECS] the big artillery


On Nov 4, 2014, at 2:52 PM, Michael Deckers via LEAPSECS 
leapsecs@leapsecond.com wrote:

 
   On 2014-11-04 12:34, Zefram wrote:
 
 UT1 always ticks a second for that ERA increase, but Warner's point
 is that the second of UT1 isn't an *SI* second.  

It is not, and cannot be a SI second, except by accident from time to time.
If it were an SI second, then TAI would never need leap seconds because
there cannot be any divergence, by definition. If two clocks tick at exactly
the same rate, their phase relationship cannot change. This is why TAI
time and GPS time are not diverging.

 The time taken for
 that ERA increase, and hence the duration of a UT1 second, very rarely
 exactly matches an SI second.  The second of UT1 is an angular unit,
 defined as 1/86400 circle (= 15 arcseconds), not a unit of physical time.
 
   Then which unit would that be? When the IERS compute a difference
   TAI - UT1, how do they do it? Do they convert the UT1 reading in
   any way before they subtract? Or, if they don't, what is the unit
   of the difference, SI seconds or second of UT1?  The IERS
   Conventions certainly do not mention any of this. How could they
   if the units would really differ?

The only practicable way to compute the difference is to compute the phase
of the two time scales, in cycles or radians, at a common point in time. Once
you have a phase difference in cycles, you can get the time difference by
converting cycles to seconds. I imagine they choose SI seconds for this last
conversion. This ‘common point in time’ is what I called the ‘grid’ in an 
earlier
post. A grid is just a set of common times spaced evenly out.

The cycles are of different size, to be true, but that turns out not to matter. 
You
are measuring the phase difference in cycles.

So to take an example. Let’s say you have two oscillators. Let’s say for the 
sake
of argument that you don’t know the true value of either of them. Let’s further 
say
that the first one happens to be 1.000 000 Hz while the second one is 1.000 001 
Hz.
They differ by a part in 10^6. Now, just to run through the math, we’ll ignore 
the
effects of any frequency drift, flicker, etc. In a real system, you’d have to 
take those
into account. Let’s also make the job easier by saying that at time t_0 they 
both start
in phase.

After 10^6 seconds, the phase of the first one is 1 000 000.000 000 000 000 and 
the
phase of the second one is 999 999.000 000 999 999. The phase difference between
these two would be 0.999 999 000 001 cycles.

If each one of these signals represented a ‘second’ then you’d have a phase
difference of 0.999 999 000 001 seconds (using the first reference) or a 
difference
of 0.999 998 000 003 using the second one as the reference second. This gives a
difference between the two types of seconds of 0.000 001 seconds or about one 
part
in 10^6. This is in line frequency error. So unless you are computing the phase
difference to 5 or more places after the decimal, you won’t see a difference.

Now, back to the SI second vs the UT1 second. The UT1 second is 1E-8 or 1E-9 
different
from the SI second. Unless they are computing the results to 7 or more digits, 
the answers
will be identical, no matter which definition of second you use.

Warner


signature.asc
Description: Message signed with OpenPGP using GPGMail
___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs

Re: [LEAPSECS] the big artillery


On Nov 4, 2014, at 6:07 AM, Zefram zef...@fysh.org wrote:

 Warner Losh wrote:
 Users can only get UTC(foo) or a signal derived from UTC(foo) (e.g.,
 traceable to NIST) and never UTC itself. Of course they can get to a
 putative TAI(foo) trivially (I say putative, because as far as I know, no
 lab generates TAI synchronized signals for reasons you go into). However,
 they cannot get back to TAI(BIPM)
 ...
 That's the hair I'm trying to split.
 
 I'm not seeing the split.  I think you've just said exactly the same
 things about TAI and UTC, and hence agreed with me.  Let's see:
 
 A user can listen to a radio time:  A user can listen to a radio time
 signal that provides PPS markers :  signal that provides PPS markers
 synched to UTC(national_lab) :  synched to TAI(national_lab)
 along with time codes that can   :  along with time codes that can
 be decoded to UTC(national_lab). :  be decoded to TAI(national_lab).
 UTC(national_lab) is not exactly :  TAI(national_lab) is not exactly
 the same as UTC(BIPM), but tends :  the same as TAI(BIPM), but tends
 to be within tens of nanoseconds :  to be within tens of nanoseconds
 of it.  UTC(BIPM) (the canonical :  of it.  TAI(BIPM) (the canonical
 UTC) is not precisely available  :  TAI) is not precisely available
 in real time: it is determined   :  in real time: it is determined
 retrospectively by comparing the :  retrospectively by comparing the
 clocks of the various national   :  clocks of the various national
 labs.  UTC(national_lab) timestamps  :  labs.  TAI(national_lab) timestamps
 can be corrected to UTC(BIPM):  can be corrected to TAI(BIPM)
 retrospectively by applying the  :  retrospectively by applying the
 offsets given in Circular T. :  offsets given in Circular T.
 
 Which part of this is wrong, for which time scale?
 
 Of course, I'm referring to the same radio signal in each case, and the
 PPS markers are the same.  The decoding process is slightly different,
 but with ready availability of the TAI-UTC difference it's not appreciably
 more difficult.  The national lab's job of steering clocks and generating
 the signal is the same in both views.  The received signal is traceable
 to the national lab and ultimately to BIPM in both views.  The only
 remaining asymmetry is that the TAI(national_lab) notation isn't
 officially approved, but that doesn't diminish the concept.

The markers aren’t the same. TAI doesn’t actually exist until after the fact.
That’s the point I’m trying to make. BIPM maintains TAI and UTC as paper
time scales (see http://tf.nist.gov/general/pdf/1498.pdf). Different national
labs steer all their clocks to what they thing UTC should be, and distribute
that. Although technically a paper clock UTC is very much seen as the
operational side of things. It is realized in real time, everybody exchanges
time stamps based on UTC as seen on the GPS constellation (so UTC(USNO))
etc. TAI is viewed more the source of truth, but finding that truth is done
after the fact.

Could one create, in real time, a TAI signal, sure. But no one does.

 There is no technical difference here, only a political difference.

The difference is also philosophical. TAI is for the BIPM time geeks to tinker 
with,
and get in closer alignment with TT over time. It’s very much oriented to the
paper clock aspect of things, with much tinkering of data. It is more than just 
a labeling
of seconds. It connotes all these other things which are published on a regular
schedule, just not a real time schedule. UTC, while also a paper clock, is also 
more
than just a labeling of seconds. It is the operational time scale. It is the 
one everybody
is using to coordinate time, to get their notion of civil time, etc.

So while an outside may see “oh! look! TAI is a nice way to label seconds that
doesn’t suffer from the leap second issue, let’s use it!” the insider reacts to 
that suggestion
with horror because they know all the behind the scenes machinations. They know 
that
TAI isn’t a time scale produced in real time. It is the connotations of the 
terms that cause
this reaction.

So maybe I’m again off in the weeds trying to differentiate between philosophy 
and a
notion of the right thing and politics and ideology.

Warner


signature.asc
Description: Message signed with OpenPGP using GPGMail
___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs

Re: [LEAPSECS] the big artillery

2014-11-05 Thread Tony Finch

Steve Allen s...@ucolick.org wrote:

 By the way, which USNO table is that?

http://maia.usno.navy.mil/ser7/tai-utc.dat

Tony.
-- 
f.anthony.n.finch  d...@dotat.at  http://dotat.at/
Southwest Forties, Cromarty, Forth, Tyne, Dogger: Northerly 4 or 5, becoming
variable 3 or 4, then southerly 5 to 7 later. Moderate or rough. Showers.
Good.
___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs

Re: [LEAPSECS] the big artillery

2014-11-05 Thread Zefram

Warner Losh wrote:
The markers aren't the same.

I was referring to the PPS marks in a time signal, and because TAI and UTC
tick the same seconds the marks work equally well for both.  Taking MSF
as a specific example, the onset of each per-second carrier-suppressed
interval (specifically, the instant when that point in the signal leaves
the transmitter) occurs at the top of a second of UTC(NPL).  UTC is always
an integral number of seconds offset from TAI, and so by construction
UTC(NPL) is always an integral number of seconds offset from TAI(NPL).
Hence each of the marks also occurs at the top of a second of TAI(NPL).

TAI doesn't actually exist until after the fact.

Nor does UTC.

Could one create, in real time, a TAI signal, sure. But no one does.

Taking MSF again as a specific example, it's just as much a TAI signal
as it is a UTC signal.  The PPS marks serve equally well for both,
subject to the UTC(NPL)-UTC = TAI(NPL)-TAI realisation error.  The time
code transmitted alongside the marks doesn't directly encode either UTC
or TAI, so decoding to either requires some out-of-band information.
(The broken-down time that is directly encoded is in UTC plus the UK's
current timezone offset, and nothing in the signal says what that offset
is.  There's a bit saying whether the offset includes DST, but there's
nothing saying what the winter-time offset is.  The signal format spec
http://www.npl.co.uk/upload/pdf/MSF_Time_Date_Code.pdf is clear that
a change to the UK's winter-time offset wouldn't be detectable from the
post-change signal.)

So while an outside may see oh! look! TAI is a nice way to label seconds that
doesn't suffer from the leap second issue, let's use it! the insider reacts 
to that suggestion
with horror because they know all the behind the scenes machinations.

The same machinations also lie behind UTC.

So maybe I'm again off in the weeds trying to differentiate between philosophy 
and a
notion of the right thing and politics and ideology.

I'm open to there being philosophical differences, and of course
taking UTC as a whole it certainly does have such differences from TAI.
But (for the leap-seconds form of UTC) those differences are only in how
the seconds are labelled.  At the sub-second level, UTC incorporates
TAI's features in their entirety, by reference.  Identical behaviour,
identical philosophy guiding that behaviour.

-zefram
___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs

Re: [LEAPSECS] the big artillery

2014-11-05 Thread Steve Allen

On Wed 2014-11-05T15:49:05 +, Tony Finch hath writ:
 Steve Allen s...@ucolick.org wrote:
  By the way, which USNO table is that?

 http://maia.usno.navy.mil/ser7/tai-utc.dat

Yes, that is the table from the BIH, who were given responsibility
for the coordination as of the beginning of 1961.
The data for TAI-UTC (neither of which existed by that name) during
1960 in SoFA are very likely the ones from US NBS which can be found
in the 1992 edition of the Explanatory Supplement.

--
Steve Allen s...@ucolick.orgWGS-84 (GPS)
UCO/Lick Observatory--ISB   Natural Sciences II, Room 165Lat  +36.99855
1156 High StreetVoice: +1 831 459 3046   Lng -122.06015
Santa Cruz, CA 95064http://www.ucolick.org/~sla/ Hgt +250 m
___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs

Re: [LEAPSECS] the big artillery

2014-11-05 Thread David Malone

On Wed, Nov 05, 2014 at 04:27:19PM +, Zefram wrote:
 UTC is always
 an integral number of seconds offset from TAI, and so by construction
 UTC(NPL) is always an integral number of seconds offset from TAI(NPL).

I don't see how the first follows from the second here, particularly
if you consider UTC(X) to be the transmitted version. For example,
if you transmit a second boundary at what you later identify to be
the wrong time, you can correct for that in your paper estimate of
TAI(X) so that it does may not align with UTC(X). This corrected
estimate of TAI(X) would then, presumably, be what as an input to
the calculation of TAI, and subsequently UTC.

David.
___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs

Re: [LEAPSECS] the big artillery

2014-11-05 Thread Zefram

David Malone wrote:
if you transmit a second boundary at what you later identify to be
the wrong time, you can correct for that in your paper estimate of
TAI(X) so that it does may not align with UTC(X).

That's not what I mean by TAI(k).  You're describing having two distinct
time scale realisation efforts from one authority, but my situation
involves applying a single realisation effort to both time scales.
I define

TAI(k) = TAI + (UTC(k)-UTC) = UTC(k) + (TAI-UTC)

It follows that

TAI(k) - UTC(k) = TAI - UTC
TAI(k) - TAI = UTC(k) - UTC

(Around leap seconds, TAI-UTC in the above expressions must be
understood to refer to the difference that is appropriate for the UTC(k)
value in question.)

  This corrected
estimate of TAI(X) would then, presumably, be what as an input to
the calculation of TAI, and subsequently UTC.

The steering of TAI is based on the comparisons made between the clocks of
the national labs.  Those comparisons are no longer made via the public
time signals broadcast by the individual labs, so conceptually there is
room for a distinction between the TAI/UTC realisation embodied in MSF and
the TAI/UTC realisation that constitutes NPL's contribution to TAI(BIPM).
I'm somewhat curious as to how this distinction plays out in practice.
But it's irrelevant to my argument here, which is why I ignored it,
just like I ignored the issue of the time signal receiver imperfectly
realising UTC(NPL) from the signal.

-zefram
___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs

Re: [LEAPSECS] the big artillery

2014-11-05 Thread Michael Deckers via LEAPSECS



  On 2014-11-04 22:26, Steve Allen wrote:


Guinot explained this using the term graduation second
in section 2.2 of 1995 Metrologia 31 431
http://iopscience.iop.org/0026-1394/31/6/002

He points out that the way the IAU has written the definitions of the
time scales uses a subtly ambiguous notation.  He writes

   The numerical value of UT1(IERS)-TAI does not
   of course, express a duration. In this context, the s
   only conveys the information that the readings of the
   two time scales are expressed in graduation seconds.


  Thank you for that information!

  Yes, not every quantity with dimension time is a
  duration, let alone a duration of proper time. The
  difference between clock readings need not relate
  to proper time, and not even to the same time scale.
  A few operations with durations of differing time
  scales are considered to result in durations
  (eg, a weighted average of durations measured in
  different time scales), but most can not. And a
  sedimentation rate (a quotient velocity/acceleration)
  can not be considered as a duration, nor as
  the result of any other operation with time scales.

  Nevertheless, all these quantities have the dimension
  of time and can therefore be expressed with the SI
  unit for time, even though the SI second is (currently)
  defined as a duration of proper time. This is essential
  for the meaningful operations that one wants to perform
  with these quantities (differences of clock readings,
  averages of durations), but it also makes many
  meaningless operations possible (such as subtracting
  a sedimentation rate from a clock reading).

  Michael Deckers.

___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs

Re: [LEAPSECS] the big artillery

2014-11-05 Thread Michael Deckers via LEAPSECS

On 2014-11-05 11:28, Steffen Nurpmeso wrote:

Oh, the German Physikalisch-Technische Bundesanstalt (PTB) also
has a general -- at least -- overview of the set of problems.
(English: [1] and all around that; oops, not everything is
translated, what a shame! I hope it's not due to lack of
resources, which seems to become notorious in Germany [for things
that really matter at least].)
..
[1]
https://www.ptb.de/cms/en/fachabteilungen/abt4/fb-44/ag-441/realisation-of-the-si-second.html
Rest under

https://www.ptb.de/cms/en/fachabteilungen/abt4/fb-44/ag-441/realisation-of-legal-time-in-germany/

The very beginning of the last reference is misleading and
wrong:

Properties of UTC

The time scale UTC (Coordinated Universal Time) owes its
existence to the CCIR (International Consultative Committee
of Radiocommunications) of the ITU (International
Telecommunications Union) which proposed to broadcast
time signals worldwide in a coordinated way, i.e.
by reference to a common time scale.

The concept for UTC was devised by people from the BIH
and some other metrology institutes, not by the CCIR;
and the CCIR has never produced a time scale. It is
unfortunate that most sources about time and time scales
are full of inaccuracies and errors like these, perpetuated
through hundreds of papers and books.

Steve Allen's page
[http://www.ucolick.org/~sla/leapsecs/timescales.html]
gives a carefully researched, reliable account of the history
of UTC and other time scales, based on the primary sources.
It is the result of an enormous labor in extracting the facts
from a mixture with myth and hearsay.

Michael Deckers.

___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs

Re: [LEAPSECS] the big artillery

2014-11-05 Thread Michael Deckers via LEAPSECS



   On 2014-11-05 16:27, Zefram wrote:


...  UTC is always
an integral number of seconds offset from TAI, and so by construction
UTC(NPL) is always an integral number of seconds offset from TAI(NPL).
Hence each of the marks also occurs at the top of a second of TAI(NPL).


  The symbol TAI(k) is defined in
  RECOMMENDATION ITU-R TF.536-2: Time-scale notations
  of 2003 with the text:

  TAI(k): Time-scale realized by the institute “k” and defined
  by the relation TAI(k) = UTC(k) + DTAI, where DTAI
  is the number of integral seconds specified by the
  International Earth Rotation Service (IERS) as
  being the difference between UTC and TAI;

  I do not know whether that notation has ever been put
  to serious use outside this recommendation.

  The contributions by the various metrology institutes to TAI
  are independent from the UTC(k) and are denoted by TA(k) in
  Circular T by the BIPM. The recommendation explains it as:

  TA(k): Atomic Time-scale, as realized by the institute “k”;

  Michael Deckers.

___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs

Re: [LEAPSECS] the big artillery


On Nov 5, 2014, at 10:54 AM, Zefram zef...@fysh.org wrote:

 David Malone wrote:
 if you transmit a second boundary at what you later identify to be
 the wrong time, you can correct for that in your paper estimate of
 TAI(X) so that it does may not align with UTC(X).
 
 That's not what I mean by TAI(k).  You're describing having two distinct
 time scale realisation efforts from one authority, but my situation
 involves applying a single realisation effort to both time scales.
 I define
 
TAI(k) = TAI + (UTC(k)-UTC) = UTC(k) + (TAI-UTC)
 
 It follows that
 
TAI(k) - UTC(k) = TAI - UTC
TAI(k) - TAI = UTC(k) - UTC
 
 (Around leap seconds, TAI-UTC in the above expressions must be
 understood to refer to the difference that is appropriate for the UTC(k)
 value in question.)

Except that’s not how others define it. Given that definition, our discussion 
makes
better sense now. FOO(x) is the FOO timescale as realized by x. You have to
have actual clocks or oscillators ticking the signals out. To while UTC(x) 
exists for
a large number of x, TAI(x) doesn’t. You can find the corresponding TAI time 
for any
x’s UTC(x) after the fact when  BIPM publishes the data.

What you should be writing is something more like TAI(UTC(x)) to denote that
you are deriving TAI form UTC(x), not that x is realizing TAI.

Warner



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs

Re: [LEAPSECS] the big artillery


On Nov 5, 2014, at 1:59 PM, Michael Deckers via LEAPSECS 
leapsecs@leapsecond.com wrote:

 
   On 2014-11-05 16:27, Zefram wrote:
 
 ...  UTC is always
 an integral number of seconds offset from TAI, and so by construction
 UTC(NPL) is always an integral number of seconds offset from TAI(NPL).
 Hence each of the marks also occurs at the top of a second of TAI(NPL).
 
  The symbol TAI(k) is defined in
  RECOMMENDATION ITU-R TF.536-2: Time-scale notations
  of 2003 with the text:
 
  TAI(k): Time-scale realized by the institute “k” and defined
  by the relation TAI(k) = UTC(k) + DTAI, where DTAI
  is the number of integral seconds specified by the
  International Earth Rotation Service (IERS) as
  being the difference between UTC and TAI;
 
  I do not know whether that notation has ever been put
  to serious use outside this recommendation.

Ah, that’s interesting. That also post-dates my research about what
to call a TAI time scale that’s based on UTC for our product. Outside
of this list, I’ve not seen TAI(k) and had been told that the notation
I posted would likely be what people would expect, but it would be
even better if we called it something else entirely to avoid confusion.
At the time, I couldn’t find anything beyond ‘Please don’t call something
you do TAI unless you are BIPM’ :).

Warner



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs

Re: [LEAPSECS] the big artillery

2014-11-05 Thread Steve Allen

On Wed 2014-11-05T14:50:06 -0700, Warner Losh hath writ:
 On Nov 5, 2014, at 1:59 PM, Michael Deckers via LEAPSECS 
 leapsecs@leapsecond.com wrote:
   The symbol TAI(k) is defined in
   RECOMMENDATION ITU-R TF.536-2: Time-scale notations
   of 2003 with the text:

 At the time, I couldn't find anything beyond Please don't call something
 you do TAI unless you are BIPM :).

http://www.itu.int/rec/R-REC-TF.536/en

TF.536 is not in force.  It was suppressed on 2011-02-18
I think there might be some get off my lawn in the story behind that.

--
Steve Allen s...@ucolick.orgWGS-84 (GPS)
UCO/Lick Observatory--ISB   Natural Sciences II, Room 165Lat  +36.99855
1156 High StreetVoice: +1 831 459 3046   Lng -122.06015
Santa Cruz, CA 95064http://www.ucolick.org/~sla/ Hgt +250 m
___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs

Re: [LEAPSECS] the big artillery

2014-11-05 Thread Alex Currant via LEAPSECS

Despite what the recommendations might say, I think the TA(k) reported in the 
Circular T are not efforts by lab K to realize TAI.  They are probably 
unsteered timescales generated by the labs for their internal use.   The values 
for USNO and NIST are extremely large, for example.   That whole section of the 
Circular T could be just a vestigial contribution from a bygone era.    Those 
who needed to interface with civil time used UTC, and it seems those who needed 
a continuous timescale did whatever seemed easiest at the time.   

 

 From: Michael Deckers via LEAPSECS leapsecs@leapsecond.com
 To: Leap Second Discussion List leapsecs@leapsecond.com 
 Sent: Wednesday, November 5, 2014 3:59 PM
 Subject: Re: [LEAPSECS] the big artillery
   

    On 2014-11-05 16:27, Zefram wrote:

 ...  UTC is always
 an integral number of seconds offset from TAI, and so by construction
 UTC(NPL) is always an integral number of seconds offset from TAI(NPL).
 Hence each of the marks also occurs at the top of a second of TAI(NPL).

  The symbol TAI(k) is defined in
      RECOMMENDATION ITU-R TF.536-2: Time-scale notations
  of 2003 with the text:

  TAI(k): Time-scale realized by the institute “k” and defined
          by the relation TAI(k) = UTC(k) + DTAI, where DTAI
          is the number of integral seconds specified by the
          International Earth Rotation Service (IERS) as
          being the difference between UTC and TAI;

  I do not know whether that notation has ever been put
  to serious use outside this recommendation.

  The contributions by the various metrology institutes to TAI
  are independent from the UTC(k) and are denoted by TA(k) in
  Circular T by the BIPM. The recommendation explains it as:

  TA(k): Atomic Time-scale, as realized by the institute “k”;

  Michael Deckers.

___
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

Re: [LEAPSECS] the big artillery

2014-11-05 Thread Alex Currant via LEAPSECS

Despite what the recommendations might say, I think the TA(k) reported in the 
Circular T are not efforts by lab K to realize TAI, since it is hard to imagine 
how a lab could get a different offset attempting to realize TAI from 
attempting to realize UTC. The values for USNO and NIST are extremely large, 
for example  The TA(k) are probably unsteered timescales generated by the labs 
for their internal use.
 On the other hand, maybe that whole section of the Circular T is just a 
vestigial contribution from a bygone era.    Those who needed to interface with 
civil time used UTC, and it seems those who needed a continuous timescale did 
whatever seemed easiest at the time.   Today, those who need a continuous 
timescale to interface with civil time, or who don't know what they are doing, 
can always be pleasantly surprised by a chance to earn overtime at New Year's 
or on July 1. 

 

 From: Michael Deckers via LEAPSECS leapsecs@leapsecond.com
 To: Leap Second Discussion List leapsecs@leapsecond.com 
 Sent: Wednesday, November 5, 2014 3:59 PM
 Subject: Re: [LEAPSECS] the big artillery
   

    On 2014-11-05 16:27, Zefram wrote:

 ...  UTC is always
 an integral number of seconds offset from TAI, and so by construction
 UTC(NPL) is always an integral number of seconds offset from TAI(NPL).
 Hence each of the marks also occurs at the top of a second of TAI(NPL).

  The symbol TAI(k) is defined in
      RECOMMENDATION ITU-R TF.536-2: Time-scale notations
  of 2003 with the text:

  TAI(k): Time-scale realized by the institute “k” and defined
          by the relation TAI(k) = UTC(k) + DTAI, where DTAI
          is the number of integral seconds specified by the
          International Earth Rotation Service (IERS) as
          being the difference between UTC and TAI;

  I do not know whether that notation has ever been put
  to serious use outside this recommendation.

  The contributions by the various metrology institutes to TAI
  are independent from the UTC(k) and are denoted by TA(k) in
  Circular T by the BIPM. The recommendation explains it as:

  TA(k): Atomic Time-scale, as realized by the institute “k”;

  Michael Deckers.

___
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

Re: [LEAPSECS] the big artillery

michael.deckers via LEAPSECS wrote:
   UT1 is a timescale that ticks 1 SI second when the Earth Rotation Angle
   increases by exactly (2 rad)/86 636.546 949 141 027 072,

Which it rarely does for any length of time.

On the contrary, the fixed angular speed d(ERA)/d(UT1) is a
defining property of UT1,

UT1 always ticks a second for that ERA increase, but Warner's point
is that the second of UT1 isn't an *SI* second.  The time taken for
that ERA increase, and hence the duration of a UT1 second, very rarely
exactly matches an SI second.  The second of UT1 is an angular unit,
defined as 1/86400 circle (= 15 arcseconds), not a unit of physical time.

Of course, due to the history, we alias angular seconds to physical
seconds all over the place, especially in the mathematical expressions
that we use to describe relationships between time scales.  Usually we
gloss over that by just calling them both second.  But if you're going
to specify which type of second you mean, better pick the right one for
the time scale.

-zefram
___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs

Re: [LEAPSECS] the big artillery

Warner Losh wrote:
Users can only get UTC(foo) or a signal derived from UTC(foo) (e.g.,
traceable to NIST) and never UTC itself. Of course they can get to a
putative TAI(foo) trivially (I say putative, because as far as I know, no
lab generates TAI synchronized signals for reasons you go into). However,
they cannot get back to TAI(BIPM)
...
That's the hair I'm trying to split.

I'm not seeing the split.  I think you've just said exactly the same
things about TAI and UTC, and hence agreed with me.  Let's see:

A user can listen to a radio time:  A user can listen to a radio time
signal that provides PPS markers :  signal that provides PPS markers
synched to UTC(national_lab) :  synched to TAI(national_lab)
along with time codes that can   :  along with time codes that can
be decoded to UTC(national_lab). :  be decoded to TAI(national_lab).
UTC(national_lab) is not exactly :  TAI(national_lab) is not exactly
the same as UTC(BIPM), but tends :  the same as TAI(BIPM), but tends
to be within tens of nanoseconds :  to be within tens of nanoseconds
of it.  UTC(BIPM) (the canonical :  of it.  TAI(BIPM) (the canonical
UTC) is not precisely available  :  TAI) is not precisely available
in real time: it is determined   :  in real time: it is determined
retrospectively by comparing the :  retrospectively by comparing the
clocks of the various national   :  clocks of the various national
labs.  UTC(national_lab) timestamps  :  labs.  TAI(national_lab) timestamps
can be corrected to UTC(BIPM):  can be corrected to TAI(BIPM)
retrospectively by applying the  :  retrospectively by applying the
offsets given in Circular T. :  offsets given in Circular T.

Which part of this is wrong, for which time scale?

Of course, I'm referring to the same radio signal in each case, and the
PPS markers are the same.  The decoding process is slightly different,
but with ready availability of the TAI-UTC difference it's not appreciably
more difficult.  The national lab's job of steering clocks and generating
the signal is the same in both views.  The received signal is traceable
to the national lab and ultimately to BIPM in both views.  The only
remaining asymmetry is that the TAI(national_lab) notation isn't
officially approved, but that doesn't diminish the concept.

There is no technical difference here, only a political difference.

-zefram
___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs

Re: [LEAPSECS] the big artillery

Brooks Harris wrote:
The discussion attempts to resolve the question about what the
TAI/UTC relationship was *before* 1972-01-01T00:00:00Z and how this
is related to POSIX and represented by 8601.

The actual historical relationship between TAI and UTC prior to 1972
is defined by the well-known tai-utc.dat file.  1970-01-01 falls within
the rubber-seconds era of UTC, and the file gives the expression

TAI-UTC=   4.2131700 S + (MJD - 39126.) X 0.002592 S

Applying this, we find that 1970-01-01T00:00:00 TAI was approximately
1969-12-31T23:59:51. UTC.  The fractional part of the seconds value is
exactly 1827/10003 (which can't be expressed in ISO 8601 syntax).
That's the PTP epoch expressed in the actual historical UTC; no other
value is correct.  POSIX is irrelevant to this, and ISO 8601 merely
provides the syntax to describe the approximate result.

   the term UTC may or
may not be applicable to date-time before 1972

Many things referring to UTC only address the leap-seconds era, and
so don't apply pre-1972.  The PTP spec's conversion of its epoch to UTC
is one of the relatively rare cases of actually engaging with pre-1972
UTC and using it correctly.  So in this case the term does apply.

Although I applaud the correctness, the PTP spec actually wins very
little by including the UTC conversion.  As previously discussed in the
context of your CCT proposal, PTP never actually processes timestamps
anywhere near its origin: it suffices to define the relationship between
PTP scalar values and TAI only for current times.  Defining the epoch
as 1970-01-01T00:00:00 TAI is in itself a neat way of defining the
relationship, but the conversion to UTC is much less neat.

Presumably the intent of the conversion was to clarify the specification
of the epoch.  For me it succeeds in that, because I recognise the two
expressions as describing almost the same time (within a microsecond),
and this clarifies that where the spec says TAI it really means it.
However, by sowing the confusion into which you have fallen, it seems
that the clarification is counterproductive for readers not familiar
with rubber-seconds UTC.

   The conclusion is that the PTP Epoch is
1970-01-01T00:00:00 (TAI) which *must be treated as*
1969-12-31T23:59:50Z (UTC), *not* 1969 23:59:51.18 UTC as
stated in the 1588/PTP document. The reason is to maintain an
integral-second alignment between the PTP Timescale and the UTC
timescale.

That's a ridiculous conclusion.  Integral-second alignment between
the PTP timescale (effectively TAI) and UTC, for the pre-1972 era, is
irrelevant, because no one actually used PTP in that era.  It's also
impossible to achieve with the real UTC, both because UTC and TAI had
a frequency offset in that era (so a UTC second isn't an integral TAI
second) and because of the irregular leap at the end of 1971 (so that
there weren't an integral number of UTC seconds between second-aligned
UTC times -- it's not aligned with *itself*).

Your treating it as a second-aligned UTC time amounts to inventing a
fictitious proleptic leap-seconds UTC.  It's not wrong to invent such
a beast, but it is wrong to call it UTC without qualification, as you
did earlier in this thread (and as you also did in the initial version
of your CCT proposal).  You should always explicate when you're using
such a non-standard time scale.

Furthermore, you've invented a proleptic leap-seconds UTC *badly*.  That 2
s difference between your proleptic UTC and the real UTC illustrates
that yours is tracking UT1 poorly.  This happens because (as with the
CCT proposal) you've supposed that there are no leap seconds in the
proleptic era.  If you're going to have a proleptic leap-seconds UTC,
you need to schedule some proleptic leap seconds to maintain tracking.
For example, Tony Finch's proleptic leap-seconds UTC (pUTC, extending
back to 1958-01-01) has leaps at 1971-06-30 and 1970-06-30, so the PTP
epoch is exactly 1969-12-31T23:59:52 pUTC.  You do get integral-seconds
alignment between TAI and pUTC.

So, in summary, your pseudo-UTC is pointless, misrepresented, and
defective.

-zefram
___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs

Re: [LEAPSECS] the big artillery

2014-11-04 Thread Gerard Ashton

Of course Brooks Harris is free to define proleptic UTC any way he pleases
within the confines of a document he has control over, including a post to
this mailing list. But I think the term proleptic UTC, outside the
confines of a document that gives it a proprietary definition, could mean a
variety of things. For example, the Standards of Fundamental Astronomy
subroutine  iauDat provides the delta between TAI and UTC, and the source
code comments say UTC began at 1960 January 1.0 (JD 2436934.5) and it is
improper to call the function with an earlier date. In as much as UTC
attempted to track UT2 in the 1960s, I would regard 1960 January 1.0 as the
dividing point between proleptic UTC and UTC, and I would regard proleptic
UTC as synonymous with UT2. If it turns out that creates a discontinuity at
the dividing point, so be it.

___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs

Re: [LEAPSECS] the big artillery

Brooks Harris wrote:
On 2014-11-04 09:04 AM, Zefram wrote:
POSIX is irrelevant to this,
I don't think so. 1588/PTP references POSIX and (POSIX) algorithms
many times, first in the main definition of the PTP Epoch -

The note 1 that you quote doesn't make POSIX relevant to the definition
of the PTP epoch.  All it's pointing out is that the algorithm needed
to convert between a PTP scalar value and a broken-down TAI time is
identical to the POSIX-specified algorithm to convert between a time_t
and a broken-down UTC time.  Its wording is less than clear.

Annex B is a long detailed explanation of how PTP was (evidently)
designed to be compatible with POSIX.

It sounds as though Annex B may contain actual errors, in such things
as the interpretation of POSIX time_t.  Good job it's not normative.

Well, I hope I haven't fallen into the confusion.

You appear to have mistaken your pseudo-UTC for real UTC.  You have been
confused into thinking that the rubber-seconds era of UTC somehow poses
a problem for PTP.

Not only my conclusion, and no more ridiculous than NTP' and POSIX's
similar use.

NTP and POSIX do not imply anything about pre-1972 relationship between
TAI and UTC.  Both of them work exclusively with UTC, and it is no
problem to them that their epochs lie in the rubber-seconds era (POSIX)
or entirely prior to the existence of TAI and UTC (NTP).  Scalar value
differences in NTP and POSIX time_t depend only on the number of UTC
days in the period in question, not on the number of leap seconds in
the period.  We've been through this before, around your CCT proposal.

OK. I'm using the term proleptic UTC is the same sense NTP
exrapolates date-time into the past.

Not the same at all.  NTP's proleptic UTC has an explicitly unknown
leap schedule, because the leap schedule makes no difference to NTP.
As a result, even though NTP explicitly refers to 1972 as the beginning
of UTC, its proleptic UTC is actually entirely compatible with the real
rubber-seconds UTC.  Your proleptic UTC has a specific pre-1972 leap
schedule, one which conflicts with the real pre-1972 UTC.

I would define it thus -

Proleptic UTC -

Unclear definition, as you don't address what should be the underlying
reference time scale (taking the role of TAI).  Bad name, because
proleptic UTC is a description for a class of time scales.  Even worse
name because your time scale isn't even in this class: it isn't proleptic
to (the whole of) UTC, it's only proleptic to *the leap-seconds era
of* UTC.  Also, as previously noted, an empty leap schedule makes a bad
proleptic extension of any part of UTC.

On this proleptic UTC timescale, NTP picked 1900-01-01T00:00:00Z
(proleptic UTC) as its (era 0) epoch, POSIX, 1970-01-01T00:00:00Z
(proleptic UTC), and 15888/PTP, 1969-01-01T23:59:50Z (proleptic UTC).
I really didn't make something new up - I just gave the idea a name.

As I noted above, the nature of the prolepsis for NTP and POSIX is
qualitatively different from the prolepsis you're using to describe the
PTP epoch as 1969-01-01T23:59:50Z.  What you're using for PTP there isn't
something taken from NTP or POSIX.  I don't know whether you invented it;
you're certainly not the *only* person to have invented it.  As for naming
it, in mid:5453c968.9050...@edlmax.com you referred to it using only the
ISO 8601 Z, implying UTC, and in mid:5457c54d.6010...@edlmax.com you
explicitly referred to it as UTC.  Only when pushed have you admitted
that it's not actually UTC.  You seem to think that it's somehow a
uniquely correct proleptic extension of the leap-seconds era of UTC,
which is far from the case.

   This happens because (as with the
CCT proposal) you've supposed that there are no leap seconds in the
proleptic era.
Correct. Same as NTP and POSIX.

As noted above, NTP and POSIX do not imply any specific proleptic
leap schedule.  Back in mid:20140118110620.gm21...@fysh.org in the
CCT thread I asked where you got the idea that NTP implies no leaps
pre-1972, and you didn't answer.  As best I can tell, you've looked at
the scalar value differences, treated them as pure counts of TAI seconds,
and concluded that they imply no leaps.  But that logic would lead you
to conclude that UTC *never* leaps.  NTP scalar values and POSIX time_t
values are not pure counts of seconds, but are defined to count 86400
per UTC day regardless of leaps.

So, in summary, your pseudo-UTC is pointless, misrepresented, and
defective.
I hope you'll reconsider that.

My opinion stands.  Your parallels with NTP and POSIX are erroneous,
and your pseudo-UTC would still have the same faults even if it were
also used by such other standards.

being used by some in the 1588/PTP community. Any suggestions as to
better clarify it accepted.

I'd be happy to fully critique IEEE 1588, if someone were to provide me
with a copy.

-zefram
___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs

Re: [LEAPSECS] the big artillery


On 2014-11-04 11:53 AM, Gerard Ashton wrote:

Of course Brooks Harris is free to define proleptic UTC any way he pleases
within the confines of a document he has control over, including a post to
this mailing list. But I think the term proleptic UTC, outside the
confines of a document that gives it a proprietary definition, could mean a
variety of things.


Sure, thanks. But using a name that elicits incoming projectiles isn't 
so helpful either. I'll conjugate on, or accept suggestions for, a 
better name.



For example, the Standards of Fundamental Astronomy
subroutine  iauDat provides the delta between TAI and UTC, and the source
code comments say UTC began at 1960 January 1.0 (JD 2436934.5) and it is
improper to call the function with an earlier date.
For purposes of astronomy, and probably others, the rubber band era 
may have relevance. To call it UTC seems a bit of a stretch to me, but 
there's no generally accepted name for what Zefram calls rubber-seconds 
era of UTC. Everybody has seized the name, and attempted to give it 
some meaning other than what I, at least, consider to be its origin - 
1972-01-01T00:00:00Z, when there was exactly 10 seconds initial TAI-UTC 
offset, and when Leap Seconds were deemed to exist. As we've heard so 
often here, the term doesn't appear until sometime late in the 
development of the timescale. POSIX seized on it, NTP, PTP, and here 
another organization has extrapolated it into the past.



  In as much as UTC
attempted to track UT2 in the 1960s, I would regard 1960 January 1.0 as the
dividing point between proleptic UTC and UTC, and I would regard proleptic
UTC as synonymous with UT2. If it turns out that creates a discontinuity at
the dividing point, so be it.


That's one of the problems with UTC, isn't it? Everybody seems to have 
a slightly different idea what it is.


-B



___
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

Re: [LEAPSECS] the big artillery

Brooks Harris wrote:
To call it UTC seems a bit of a stretch to me,
but there's no generally accepted name for what Zefram calls
rubber-seconds era of UTC. Everybody has seized the name, and
attempted to give it some meaning other than what I, at least,
consider to be its origin - 1972-01-01T00:00:00Z,

The name Coordinated Universal Time and initialism UTC are used
in the IAU 1967 resolutions, referring to the rubber-seconds system.
The resolutions note some possible tweaks to the tracking system.
For example:

G. M. R. Winkler put forward a proposal to increase the tolerance
of the representation of UT2 by UTC to 300 ms and to authorize the
Director of the Bureau International de l'Heure (BIH) to change the
frequency off-sets at the beginning of any month.
...
D. Belocerkovskij confirmed that the coordination with the BIH in
frequency will continue, but that the maximum tolerance in UT2-UTC
is limited to 50 milliseconds.
...
B. Guinot asked for statements by users on whether they prefer
offsets in frequency or steps in time.

The name and initialism weren't used in the IAU 1964 or 1961 resolutions,
in places where one would expect them.  These resolutions refer to time
signals and the steering mechanism without ever naming the synthetic
time scale.

So the name was around before 1972 (though not as far back as 1961),
and did refer to the pre-1972 system.  I don't recall there ever being
controversy before on whether the rubber-seconds system is actually part
of UTC.  Those sources that use UTC to refer only to the leap-seconds
era do so merely out of ignorance.

-zefram
___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs

Re: [LEAPSECS] the big artillery

2014-11-04 Thread Steve Allen

On Tue 2014-11-04T20:27:53 +, Zefram hath writ:
 The name Coordinated Universal Time and initialism UTC are used
 in the IAU 1967 resolutions, referring to the rubber-seconds system.

And that resolution explicitly refers to the content of the new CCIR
Recommendation 374-1 which uses the phrase Universal Time UT2 and
does not use the term UTC.

Today's animated discussions about unclear terminology and lack of
congruence between agencies are nothing new.

--
Steve Allen s...@ucolick.orgWGS-84 (GPS)
UCO/Lick Observatory--ISB   Natural Sciences II, Room 165Lat  +36.99855
1156 High StreetVoice: +1 831 459 3046   Lng -122.06015
Santa Cruz, CA 95064http://www.ucolick.org/~sla/ Hgt +250 m
___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs

Re: [LEAPSECS] the big artillery

2014-11-04 Thread Michael Deckers via LEAPSECS



   On 2014-11-04 12:34, Zefram wrote:


UT1 always ticks a second for that ERA increase, but Warner's point
is that the second of UT1 isn't an *SI* second.  The time taken for
that ERA increase, and hence the duration of a UT1 second, very rarely
exactly matches an SI second.  The second of UT1 is an angular unit,
defined as 1/86400 circle (= 15 arcseconds), not a unit of physical time.


   Then which unit would that be? When the IERS compute a difference
   TAI - UT1, how do they do it? Do they convert the UT1 reading in
   any way before they subtract? Or, if they don't, what is the unit
   of the difference, SI seconds or second of UT1?  The IERS
   Conventions certainly do not mention any of this. How could they
   if the units would really differ?


Of course, due to the history, we alias angular seconds to physical
seconds all over the place, especially in the mathematical expressions
that we use to describe relationships between time scales.  Usually we
gloss over that by just calling them both second.  But if you're going
to specify which type of second you mean, better pick the right one for
the time scale.


   I am puzzled by the fact that some people do not seem to accept
   with time what they easily accept with other quantities. For instance
   in geodesy, normal height is expressed in meters (or feet) even
   though it is actually a difference in geopotential observed by
   leveling.

   The expression in meters is derived from some conventional
   normal gravity potential model; comparison with orthonormal
   height thus gives an intuitive notion of its deviation from
   the real gravity field.  But nobody calls for different units
   for orthometric and normal heights, on the grounds that a meter
   of normal height would not be an SI meter of real length
   while a meter of orthometric height would be. On the contrary,
   everybody agrees that normal and orthometric height must use
   the same unit so as to make them comparable. (And, as with time
   scales, there is a bunch of other important notions of height
   to which they need to be compared!)

   The mean solar day on the rotating surface of the Earth is
   given by the comparison of UT1 with TAI (or TT). Its value,
   d(TAI)/d(UT1)·(86 400 SI seconds) would be a bad unit of
   time because it varies remarkably with time. And the mean
   solar day in a geocentric inertial system (as used in
   satellite dynamics) is a different value altogether, namely
   d(TCG)/d(UT1)·(86 400 SI seconds) at the geocenter. Neither
   quantity is used as a unit to express UT1; instead, both
   are derived from expressions of UT1, TAI, and TCG in SI units.

   Michael Deckers.

___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs

Re: [LEAPSECS] the big artillery


On 2014-11-04 03:35 PM, Steve Allen wrote:

On Tue 2014-11-04T20:27:53 +, Zefram hath writ:

The name Coordinated Universal Time and initialism UTC are used
in the IAU 1967 resolutions, referring to the rubber-seconds system.

And that resolution explicitly refers to the content of the new CCIR
Recommendation 374-1 which uses the phrase Universal Time UT2 and
does not use the term UTC.

Today's animated discussions about unclear terminology and lack of
congruence between agencies are nothing new.
No. And its frustrating. It calls for an effort to consolidate, 
centralize, and clarify the specifications.


-Brooks



--
Steve Allen s...@ucolick.orgWGS-84 (GPS)
UCO/Lick Observatory--ISB   Natural Sciences II, Room 165Lat  +36.99855
1156 High StreetVoice: +1 831 459 3046   Lng -122.06015
Santa Cruz, CA 95064http://www.ucolick.org/~sla/ Hgt +250 m
___
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

Re: [LEAPSECS] the big artillery

I wrote:
It sounds as though Annex B may contain actual errors, in such things
as the interpretation of POSIX time_t.  Good job it's not normative.

I've now seen the actual text of Annex B (thanks to an unattributable
benefactor).  Here is my review of it.  Overall it's mostly correct,
but poorly drafted.

Part of the text risks some confusion between TAI and TT, by referring
to the SI second defining the TAI timescale.  However, the distinction
is preserved in another part of the text which describes TAI as based
on the SI second as realized on the rotating geoid.  Clearly the
authors are aware of the distinction between the theoretical ideal
and the practical realisation, but by omitting explicit description,
and textually linking the SI second directly to TAI, they risk readers
failing to appreciate this.

The text introducing UTC immediately jumps into describing ISO 8601
syntax.  This gives a misleading impression that ISO 8601 is especially
tied to UTC.  There is a part of ISO 8601 that specifically refers to
UTC, namely the zone offset syntax, but that part of the syntax isn't
mentioned here.  ISO 8601 ought to be discussed separately from the
specific time scales.

The description of UTC does attempt to cover both eras, but isn't entirely
accurate for the rubber-seconds era.  The initial description, applicable
to both eras, says that UTC and TAI differ by a constant offset
... modified on occasion.  The use of constant is dubious, because
anything that gets modified is clearly not constant.  Anyway, it appears
to refer to the offset being piecewise constant.  In the leap-seconds
era the offset does have this behaviour, but in the rubber-seconds era
the frequency shifts mean that the offset changes continuously.

The statement that UTC experiences a discontinuity at leap seconds is
misleading.  The concept of discontinuity applies to scalar quantities,
but not to a broken-down UTC time.

The description of leap-seconds UTC is correct as far as it goes.
The mention of integral second correction, although correct, conflates
two issues that would be better explicated separately: UTC only leaping
by integral seconds, and the TAI-UTC offset being integral seconds.
The description then incongruously jumps to noting that UTC and TAI
can both have timestamps broken down into the traditional components.
As with the ISO 8601 syntax, that's a more generic point that should have
been discussed separately from the specific details of the time scales.

The description of rubber-seconds UTC correctly notes the TAI-UTC offset
changing in fractions of a second, but entirely fails to mention the
frequency shifts.

The mention of POSIX jumps to ISO 8601, just as the introduction of
UTC did.  It is again incongruous.  There's a sentence about applying
the POSIX algorithm to a PTP scalar value, which says essentially
what I described as my interpretation of the note on the definition of
the PTP epoch.  It says it more clearly than that note, but still not
brilliantly.  It refers to ISO 8601 again, using the ISO 8601 textual
representation as a proxy for a broken-down time.

There's some essentially correct discussion of using the count of
accumulated leap seconds as an offset to convert between a PTP scalar
value and a POSIX time_t value.  It's described in a slightly roundabout
way, never bringing out the time_t value as an interesting product, and
again going via textual representations.  There is some justification
for this (not discussed in the text): the PTP-derived time_t values are
more strictly tied to UTC than are wild time_t values.

There is a worked example of time_t conversion, but it's rather
misleading, because it's in the rubber-seconds era, pretty much at the
POSIX epoch.  The example correctly describes the currentUtcOffset
value used in the computation being near 8 and non-integral.  The protocol
can't actually transmit a non-integer value for this parameter, but of
course it never needs to, because it never transmits pre-1972 timestamps.
It's also an era for which wild time_t values are not at all tied to UTC.
So the example is correct, but involves complications that would never be
encountered in practice.  The example should have used a modern timestamp,
probably from 2006.

The time_t example has a trivial error in using : instead of -
as the separator for the elements in an ISO 8601 date representation.

The descriptions of acquiring TAI and UTC time from NTP and GPS are
essentially correct.  The statement that NTP does not correct ... [at
leap seconds] is unclear: its intended interpretation implies that the
clocks behind NTP naturally tick UTC time and would have to be adjusted
to count TAI seconds, but actually the reverse is closer to the truth.
The subsequent sentence clarifies satisfactorily.

The table of conversion expressions between PTP, NTP, and GPS times
is correct.  The PTP-NTP conversion includes a correction for leap
seconds, and the PTP-GPS conversion does not; both of these

Re: [LEAPSECS] the big artillery

2014-11-04 Thread Joseph M Gwinn

LEAPSECS leapsecs-boun...@leapsecond.com wrote on 11/04/2014 02:45:09
PM:

 From: Brooks Harris bro...@edlmax.com
 To: leapsecs@leapsecond.com
 Date: 11/04/2014 02:45 PM
 Subject: Re: [LEAPSECS] the big artillery
 Sent by: LEAPSECS leapsecs-boun...@leapsecond.com

 On 2014-11-04 11:53 AM, Gerard Ashton wrote:
  Of course Brooks Harris is free to define proleptic UTC any way he
pleases
  within the confines of a document he has control over, including a post
to
  this mailing list. But I think the term proleptic UTC, outside the
  confines of a document that gives it a proprietary definition, could
mean a
  variety of things.

 Sure, thanks. But using a name that elicits incoming projectiles isn't
 so helpful either. I'll conjugate on, or accept suggestions for, a
 better name.

  For example, the Standards of Fundamental Astronomy
  subroutine  iauDat provides the delta between TAI and UTC, and the
source
  code comments say UTC began at 1960 January 1.0 (JD 2436934.5) and it
is
  improper to call the function with an earlier date.
 For purposes of astronomy, and probably others, the rubber band era
 may have relevance. To call it UTC seems a bit of a stretch to me, but
 there's no generally accepted name for what Zefram calls rubber-seconds
 era of UTC. Everybody has seized the name, and attempted to give it
 some meaning other than what I, at least, consider to be its origin -
 1972-01-01T00:00:00Z, when there was exactly 10 seconds initial TAI-UTC
 offset, and when Leap Seconds were deemed to exist. As we've heard so
 often here, the term doesn't appear until sometime late in the
 development of the timescale. POSIX seized on it, NTP, PTP, and here
 another organization has extrapolated it into the past.

POSIX originally cited GMT, and changed to UTC around 1988, the reason
being simply that NIST (NBS then) had gone to UTC.

Joe Gwinn
___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs

Re: [LEAPSECS] the big artillery

2014-11-04 Thread Steve Allen

On Tue 2014-11-04T21:52:05 +, Michael Deckers via LEAPSECS hath writ:
Then which unit would that be? When the IERS compute a difference
TAI - UT1, how do they do it? Do they convert the UT1 reading in
any way before they subtract? Or, if they don't, what is the unit
of the difference, SI seconds or second of UT1?  The IERS
Conventions certainly do not mention any of this. How could they
if the units would really differ?

Guinot explained this using the term graduation second
in section 2.2 of 1995 Metrologia 31 431
http://iopscience.iop.org/0026-1394/31/6/002

He points out that the way the IAU has written the definitions of the
time scales uses a subtly ambiguous notation.  He writes

  The numerical value of UT1(IERS)-TAI does not
  of course, express a duration. In this context, the s
  only conveys the information that the readings of the
  two time scales are expressed in graduation seconds.

This is basically saying that UT1(IERS)-TAI is only a difference of
two numbers.  I think it's pretty much the same as supposing that a
place with a comfortable temperature is cooling off and when the
weather is freezing then the difference
Delta T = T(deg Fahrenheit) - T(deg Celsius) = 32 degrees
and when the temperature reaches -40 then
Delta T = 0 degrees

That difference is not a temperature, just like Delta T for eclipse
timing predictions is not a duration.

--
Steve Allen s...@ucolick.orgWGS-84 (GPS)
UCO/Lick Observatory--ISB   Natural Sciences II, Room 165Lat  +36.99855
1156 High StreetVoice: +1 831 459 3046   Lng -122.06015
Santa Cruz, CA 95064http://www.ucolick.org/~sla/ Hgt +250 m
___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs

Re: [LEAPSECS] the big artillery


On 2014-11-04 03:27 PM, Zefram wrote:

Brooks Harris wrote:

To call it UTC seems a bit of a stretch to me,
but there's no generally accepted name for what Zefram calls
rubber-seconds era of UTC. Everybody has seized the name, and
attempted to give it some meaning other than what I, at least,
consider to be its origin - 1972-01-01T00:00:00Z,

The name Coordinated Universal Time and initialism UTC are used
in the IAU 1967 resolutions, referring to the rubber-seconds system.
The resolutions note some possible tweaks to the tracking system.
For example:

 G. M. R. Winkler put forward a proposal to increase the tolerance
 of the representation of UT2 by UTC to 300 ms and to authorize the
 Director of the Bureau International de l'Heure (BIH) to change the
 frequency off-sets at the beginning of any month.
 ...
 D. Belocerkovskij confirmed that the coordination with the BIH in
 frequency will continue, but that the maximum tolerance in UT2-UTC
 is limited to 50 milliseconds.
 ...
 B. Guinot asked for statements by users on whether they prefer
 offsets in frequency or steps in time.

The name and initialism weren't used in the IAU 1964 or 1961 resolutions,
in places where one would expect them.  These resolutions refer to time
signals and the steering mechanism without ever naming the synthetic
time scale.

So the name was around before 1972 (though not as far back as 1961),
and did refer to the pre-1972 system.  I don't recall there ever being
controversy before on whether the rubber-seconds system is actually part
of UTC.  Those sources that use UTC to refer only to the leap-seconds
era do so merely out of ignorance.
I'm aware of these (slightly controversial) facts. It seems most 
sensible to me that the leap-seconds era is where UTC begins, but 
there are obviously many opinions about it. Since there is controversy 
and misunderstanding about what UTC actually is, maybe there *is* a 
reason to rename it. :-(


How about Leap Second Time (LST)?  That should appeal to the 
[LEAPSECS] fans, but I'll bet I get flamed. :-)


Anyway, if the people on this list can't agree there's certainly a 
reason to clarify it.


-Brooks



-zefram
___
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

Re: [LEAPSECS] the big artillery


On 2014-11-04 04:59 PM, Zefram wrote:

I wrote:

It sounds as though Annex B may contain actual errors, in such things
as the interpretation of POSIX time_t.  Good job it's not normative.

I've now seen the actual text of Annex B (thanks to an unattributable
benefactor).  Here is my review of it.  Overall it's mostly correct,
but poorly drafted.

Part of the text risks some confusion between TAI and TT, by referring
to the SI second defining the TAI timescale.  However, the distinction
is preserved in another part of the text which describes TAI as based
on the SI second as realized on the rotating geoid.  Clearly the
authors are aware of the distinction between the theoretical ideal
and the practical realisation, but by omitting explicit description,
and textually linking the SI second directly to TAI, they risk readers
failing to appreciate this.

The text introducing UTC immediately jumps into describing ISO 8601
syntax.  This gives a misleading impression that ISO 8601 is especially
tied to UTC.  There is a part of ISO 8601 that specifically refers to
UTC, namely the zone offset syntax, but that part of the syntax isn't
mentioned here.  ISO 8601 ought to be discussed separately from the
specific time scales.

The description of UTC does attempt to cover both eras, but isn't entirely
accurate for the rubber-seconds era.  The initial description, applicable
to both eras, says that UTC and TAI differ by a constant offset
... modified on occasion.  The use of constant is dubious, because
anything that gets modified is clearly not constant.  Anyway, it appears
to refer to the offset being piecewise constant.  In the leap-seconds
era the offset does have this behaviour, but in the rubber-seconds era
the frequency shifts mean that the offset changes continuously.

The statement that UTC experiences a discontinuity at leap seconds is
misleading.  The concept of discontinuity applies to scalar quantities,
but not to a broken-down UTC time.

The description of leap-seconds UTC is correct as far as it goes.
The mention of integral second correction, although correct, conflates
two issues that would be better explicated separately: UTC only leaping
by integral seconds, and the TAI-UTC offset being integral seconds.
The description then incongruously jumps to noting that UTC and TAI
can both have timestamps broken down into the traditional components.
As with the ISO 8601 syntax, that's a more generic point that should have
been discussed separately from the specific details of the time scales.

The description of rubber-seconds UTC correctly notes the TAI-UTC offset
changing in fractions of a second, but entirely fails to mention the
frequency shifts.

The mention of POSIX jumps to ISO 8601, just as the introduction of
UTC did.  It is again incongruous.  There's a sentence about applying
the POSIX algorithm to a PTP scalar value, which says essentially
what I described as my interpretation of the note on the definition of
the PTP epoch.  It says it more clearly than that note, but still not
brilliantly.  It refers to ISO 8601 again, using the ISO 8601 textual
representation as a proxy for a broken-down time.

There's some essentially correct discussion of using the count of
accumulated leap seconds as an offset to convert between a PTP scalar
value and a POSIX time_t value.  It's described in a slightly roundabout
way, never bringing out the time_t value as an interesting product, and
again going via textual representations.  There is some justification
for this (not discussed in the text): the PTP-derived time_t values are
more strictly tied to UTC than are wild time_t values.

There is a worked example of time_t conversion, but it's rather
misleading, because it's in the rubber-seconds era, pretty much at the
POSIX epoch.  The example correctly describes the currentUtcOffset
value used in the computation being near 8 and non-integral.  The protocol
can't actually transmit a non-integer value for this parameter, but of
course it never needs to, because it never transmits pre-1972 timestamps.
It's also an era for which wild time_t values are not at all tied to UTC.
So the example is correct, but involves complications that would never be
encountered in practice.  The example should have used a modern timestamp,
probably from 2006.

The time_t example has a trivial error in using : instead of -
as the separator for the elements in an ISO 8601 date representation.

The descriptions of acquiring TAI and UTC time from NTP and GPS are
essentially correct.  The statement that NTP does not correct ... [at
leap seconds] is unclear: its intended interpretation implies that the
clocks behind NTP naturally tick UTC time and would have to be adjusted
to count TAI seconds, but actually the reverse is closer to the truth.
The subsequent sentence clarifies satisfactorily.
Thats a quick study of a deep document. You may be seeing how some feel 
its confusing.


Have a look at 8.2.4.1 General, 8.2.4.2

Re: [LEAPSECS] the big artillery

2014-11-03 Thread Zefram

Warner Losh wrote:
TAI and UTC have a fixed offset relationship, it is true. However, UTC is
computed in real time (with several varieties to choose from if you care
about the nano-seconds), but TAI is a retrospective timescale that's not
computed until after the fact.

These two notions conflict: a predetermined offset relationship means that
TAI and UTC can be trivially computed from each other, which means that
if one of them can be computed in real time then so can the other.  The
reality is that the difference between TAI and UTC is indeed predetermined
(and always integral seconds, post-1972), and *both* TAI and UTC are
paper time scales that are canonically only determined in retrospect.
Both have real-time realisations that differ by nanoseconds: each UTC(k)
realising UTC implies, via the well-known offset, a corresponding TAI(k)
realising TAI.  The notation TAI(k) isn't officially approved, but the
concept is perfectly meaningful, these time scales are readily accessible,
and they are de facto used in some applications.

There's a political shell game going on with some people trying to
suggest that there's a significant difference here between TAI and UTC,
trying to discourage the use of TAI by end users.  I can only guess at
the motivation: perhaps an attempt to keep some of the conceptual space
unsullied by the grubby mitts of actual applications.  Don't be fooled:
real-time TAI realisation is available to the masses.

-zefram
___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs

Re: [LEAPSECS] the big artillery


On Nov 3, 2014, at 3:35 AM, Zefram zef...@fysh.org wrote:

 Warner Losh wrote:
 TAI and UTC have a fixed offset relationship, it is true. However, UTC is
 computed in real time (with several varieties to choose from if you care
 about the nano-seconds), but TAI is a retrospective timescale that's not
 computed until after the fact.
 
 These two notions conflict: a predetermined offset relationship means that
 TAI and UTC can be trivially computed from each other, which means that
 if one of them can be computed in real time then so can the other.  The
 reality is that the difference between TAI and UTC is indeed predetermined
 (and always integral seconds, post-1972), and *both* TAI and UTC are
 paper time scales that are canonically only determined in retrospect.
 Both have real-time realisations that differ by nanoseconds: each UTC(k)
 realising UTC implies, via the well-known offset, a corresponding TAI(k)
 realising TAI.  The notation TAI(k) isn't officially approved, but the
 concept is perfectly meaningful, these time scales are readily accessible,
 and they are de facto used in some applications.

Except it doesn’t work that way.

The TAI timescale, as maintained by BIPM, is computed well after the fact.
You cannot know it in realtime because it is not computed in real time. The
nominal offset from UTC is a fixed number of seconds, but UTC’s realization
differs from place to place. UTC realized from the labs of NIST will have a
small offset from the UTC realized from NRAO. Since TAI isn’t realized in
realtime anywhere, you can’t possibly steer to.

You can create your own TAI, that’s traceable to a government lab UTC, but
that’s not quite the same thing. You have TAI(joe-private-citizen) not TAI(NIST)
or TAI(BIPM).

TAI is a paper clock. You can convert your time stamps you get today from
your atomic clock to TAI time stamps once the offsets (phase and frequency)
have been determined for your clock by comparing it to all the others in
the data that makes up this paper clock. Until then, you can only have
speculative or preliminary values. For most people, I’ll agree this doesn’t
matter (+36s or whatever the current offset is). For some it is quite important.

UTC is also a paper clock. However, this paper clock has actual clocks that
are tightly steered to it that people can exchange time with to steer their 
clocks
to it. That’s why the recommendations are to use UTC time.

 There's a political shell game going on with some people trying to
 suggest that there's a significant difference here between TAI and UTC,
 trying to discourage the use of TAI by end users.  I can only guess at
 the motivation: perhaps an attempt to keep some of the conceptual space
 unsullied by the grubby mitts of actual applications.  Don't be fooled:
 real-time TAI realisation is available to the masses.

Well, you can create something that’s like TAI, sure. But BIPM’s TAI is
not a real-time thing. BIPM doesn’t want people to use it because they don’t
want the hassles of having a real-time operations time scale. Use UTC for
that, they say.

That’s why people should create a new name for UTC without leap seconds.
It isn’t UTC anymore (since it has lost the trait of tracking UT1), but it isn’t
TAI either since it is realized in real time. It is trivial, as you suggest, to 
have
a TAI-like thing that is good enough for everybody (basically UTC time-scale
for phase and frequency, but with TAI-second labels instead of UTC-second
labels). But that isn’t quite TAI, but is a quite useful concept. This is why we
have Loran time, GPS time, Galileo  time, etc. There was no foresight in the
1970’s to say “here’s the atomic time scale, here’s the rotational time scale
and operationally, here’s how you convert the latter to the former.” I wonder
if any of the list historians has a good reference to the proceedings, or if 
we’re
left to speculate. My speculation is that the folks that knew TAI couldn’t get
past these trivial technical differences and so blocked its use, not realizing
that that they could still have their own stand box timescale and provide
meaningful guidance for decades to come...

Warner


signature.asc
Description: Message signed with OpenPGP using GPGMail
___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs

Re: [LEAPSECS] the big artillery

2014-11-03 Thread Greg Hennessy


On 11/03/2014 10:13 AM, Warner Losh wrote:


UTC realized from the labs of NIST will have a
small offset from the UTC realized from NRAO.


Did you mean USNO where you typed NRAO?



___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs

Re: [LEAPSECS] the big artillery


On Nov 3, 2014, at 8:19 AM, Greg Hennessy greg.henne...@cox.net wrote:

 On 11/03/2014 10:13 AM, Warner Losh wrote:
 
 UTC realized from the labs of NIST will have a
 small offset from the UTC realized from NRAO.
 
 Did you mean USNO where you typed NRAO?

Yes. My bad.

Warner



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs

Re: [LEAPSECS] the big artillery


Hi Micheal,

On 2014-11-03 02:43 AM, michael.deckers via LEAPSECS wrote:



On 2014-10-31 17:39, Brooks Harris wrote:

Yes. Its primary timescale, sometimes called PTP Time, more 
properly the PTP

Timescale, is a TAI-like counter (uninterrupted incrementing count of
seconds). Note its origin, or epoch, is 1969-12-31T23:59:50Z, ten 
seconds before
the POSIX the Epoch (if you take that to mean two years (2 x 365 x 
86400)

seconds before 1972-01-01T00:00:00Z (UTC), as NTP does).


Just nitpicking:
In [IEC 61588 of 2009-02. section 7.2.2] we read:
The PTP epoch is 1 January 1970 00:00:00 TAI,
which is 31 December 1969 23:59:51.18 UTC.
So you are off by about 2 s.


CAUTION about the PTP Epoch. Its not just nitpicking.

I have been involved with a standards body attempting to use 1588/PTP. 
There was a (long!) debate about what the PTP Epoch actually is. This 
discussion included several participants with experience using 1588/PTP. 
The conclusion is that the PTP Epoch is 1970-01-01T00:00:00 (TAI) which 
*must be treated as* 1969-12-31T23:59:50Z (UTC), *not* 1969 
23:59:51.18 UTC as stated in the 1588/PTP document. The reason is 
to maintain an integral-second alignment between the PTP Timescale and 
the UTC timescale.


The relationship between the PTP timescale, POSIX, and UTC are discussed 
in some detail in the document. Unfortunately it is confusing, 
misleading, and arguably wrong.


Quoting [IEEE Std 1588™-2008, IEEE Standard for a Precision Clock 
Synchronization Protocol for Networked Measurement and Control Systems]


7.2 PTP timescale, 7.2.1 General - The timescale PTP: In normal 
operation, the epoch is the PTP epoch and the timescale is continuous; 
see 7.2.4. The unit of measure of time is the SI second as realized on 
the rotating geoid.


This describes a TAI-like timescale - an uninterrupted incrementing 
count of seconds, and specifically  the SI second as realized on the 
rotating geoid.. That is the primary counting mechanism, appropriate to 
the main objective as stated in the title - for Networked Measurement 
and Control Systems.


7.2.2 Epoch states The PTP epoch is 1 January 1970 00:00:00 TAI, which 
is 31 December 1969 23:59:51.18 UTC.


Here we wade into the debate and confusion produced by the historical 
TAI/UTC relationship before 1972. In the same section, we read -


NOTE 1— The PTP epoch coincides with the epoch of the common Portable 
Operating System Interface (POSIX) algorithms for converting elapsed 
seconds since the epoch to the ISO 8601:2004 printed representation of 
time of day; see ISO/IEC 9945:2003 [B16] and ISO 8601:2004 [B17].


Here we wade into the debate and confusion about POSIX's The Epoch. In 
the same section, we also read -


NOTE 2— See Annex B for information on converting between common 
timescales.


In Annex B (informative) Timescales and epochs in PTP we find a long, 
detailed, discussion of timescales, especially PTP, TAI, POSIX, and UTC, 
and character representation via 8601. Note the entire annex is 
(informative).


The discussion attempts to resolve the question about what the TAI/UTC 
relationship was *before* 1972-01-01T00:00:00Z and how this is related 
to POSIX and represented by 8601. Of course, as often discussed and 
debated on this [LEAPSECS] list, the term UTC may or may not be 
applicable to date-time before 1972 and what portions of the historical 
record might be interpreted as proleptic and exactly what that means. 
One could argue the entire section is very confusing.


At the end of Annex B we find a table - Table B.1 - Relationships 
between timescales. Note the values of the relationships amongst the 
timescales in this table are all *integral second* values. This seems to 
be in contradiction to much of the discussion in Annex B and to the 
statement of the PTP Epoch in paragraph 7.2.2 Epoch.


If we parse that sentence (7.2.2 Epoch - The PTP epoch is 1 January 
1970 00:00:00 TAI, which is 31 December 1969 23:59:51.18 UTC.) 
carefully, the first part, 1 January 1970 00:00:00 TAI is clear 
enough, but exactly what to make of 31 December 1969 23:59:51.18 
UTC? That value might be correct depending on how you interpret the 
historical record of TAI/UTC offsets and exactly what you mean by some 
proleptic UTC timescale.


We've been advised by PTP experts that A) yes, its confusing, and B) 
most implementations use a integral-second interpretation, as in Table 
B.1. I understand the escape clause they use to justify this is the 
(POSIX) algorithms phrase in Note 1 of 7.2.2 Epoch. By (POSIX) 
algorithms they mean gmtime() and (strict) POSIX ticks at 1Hz, so, 
integral seconds. In any event its really the only interpretation that 
yields a manageable, practical, implementation that is consistent with 
TAI and UTC, NTP, and common-use of POSIX.


However, while its said most implementations follow this approach, it 
doesn't mean every one does. I fear there are already implementations of 
1588/PTP that do not

Re: [LEAPSECS] the big artillery


On Nov 3, 2014, at 11:11 AM, Brooks Harris bro...@edlmax.com wrote:
 CAUTION about the PTP Epoch. Its not just nitpicking”.
...
 We've been advised by PTP experts that A) yes, its confusing, and B) most 
 implementations use a integral-second interpretation, as in Table B.1. I 
 understand the escape clause they use to justify this is the (POSIX) 
 algorithms phrase in Note 1 of 7.2.2 Epoch. By (POSIX) algorithms they 
 mean gmtime() and (strict) POSIX ticks at 1Hz, so, integral seconds. In 
 any event its really the only interpretation that yields a manageable, 
 practical, implementation that is consistent with TAI and UTC, NTP, and 
 common-use of POSIX.

A few years ago, I had to produce TAI-like data from a measurement system. We 
defined the value as “seconds since 1970” but the technical definition was 
number of SI seconds since 1 Jan 1972 00:00:00 UTC + 10 + #seconds-in-197071” 
to avoid the ambiguity. Given that our chief time scientist suggested this, and 
they were quite involved in PTP…

Warner




signature.asc
Description: Message signed with OpenPGP using GPGMail
___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs

Re: [LEAPSECS] the big artillery

On 2014-11-03 02:19 PM, Warner Losh wrote:

On Nov 3, 2014, at 11:11 AM, Brooks Harris bro...@edlmax.com wrote:

CAUTION about the PTP Epoch. Its not just nitpicking.

...

We've been advised by PTP experts that A) yes, its confusing, and B) most implementations use a integral-second interpretation,
as in Table B.1. I understand the escape clause they use to justify this is the (POSIX) algorithms phrase
in Note 1 of 7.2.2 Epoch. By (POSIX) algorithms they mean gmtime() and (strict) POSIX ticks
at 1Hz, so, integral seconds. In any event its really the only interpretation that yields a manageable, practical, implementation
that is consistent with TAI and UTC, NTP, and common-use of POSIX.

A few years ago, I had to produce TAI-like data from a measurement system. We defined the value as
seconds since 1970 but the technical definition was number of SI seconds since 1 Jan
1972 00:00:00 UTC + 10 + #seconds-in-197071 to avoid the ambiguity. Given that our chief
time scientist suggested this, and they were quite involved in PTP...

I assume you mean number of SI seconds since 1 Jan 1972 00:00:00 UTC +
10 - #seconds-in-197071 ? And the #seconds-in-197071 is (2 * 365 *
86400), right? That would be coincident with the PTP Epoch as
interpreted above, that is, seconds since 1970 (TAI).

-Brooks

Warner

___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs

Re: [LEAPSECS] the big artillery


On Nov 3, 2014, at 12:53 PM, Brooks Harris bro...@edlmax.com wrote:

 On 2014-11-03 02:19 PM, Warner Losh wrote:
 On Nov 3, 2014, at 11:11 AM, Brooks Harris bro...@edlmax.com
  wrote:
 
 CAUTION about the PTP Epoch. Its not just nitpicking”.
 
 ...
 
 We've been advised by PTP experts that A) yes, its confusing, and B) most 
 implementations use a integral-second interpretation, as in Table B.1. I 
 understand the escape clause they use to justify this is the (POSIX) 
 algorithms phrase in Note 1 of 7.2.2 Epoch. By (POSIX) algorithms they 
 mean gmtime() and (strict) POSIX ticks at 1Hz, so, integral seconds. In 
 any event its really the only interpretation that yields a manageable, 
 practical, implementation that is consistent with TAI and UTC, NTP, and 
 common-use of POSIX.
 
 A few years ago, I had to produce TAI-like data from a measurement system. 
 We defined the value as “seconds since 1970” but the technical definition 
 was number of SI seconds since 1 Jan 1972 00:00:00 UTC + 10 + 
 #seconds-in-197071” to avoid the ambiguity. Given that our chief time 
 scientist suggested this, and they were quite involved in PTP…
 
 I assume you mean number of SI seconds since 1 Jan 1972 00:00:00 UTC + 10 - 
 #seconds-in-197071” ? And the #seconds-in-197071” is (2 * 365 * 86400), 
 right? That would be coincident with the PTP Epoch as interpreted above, that 
 is, seconds since 1970 (TAI)”.

TAI is ahead of UTC, so you have to add in the leap seconds to UTC to get TAI. 
At 1 jan 1972 00:00:00 UTC this offset was 10s, exactly. To bias the date back 
to 1970, you have to add in 2 * 365 * 86400, to give a value of 63072010 for 1 
jan 1972 00:00:00 UTC. I don’t think you want to subtract it, since that leads 
to an epoch of 31 DEC 1973 00:00:00 due to the leap day in 1972, right?

Warner

 -Brooks
 
 
 Warner
 
 
 
 
 
 ___
 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



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs

Re: [LEAPSECS] the big artillery




On 2014-11-03 03:04 PM, Warner Losh wrote:

On Nov 3, 2014, at 12:53 PM, Brooks Harris bro...@edlmax.com wrote:


On 2014-11-03 02:19 PM, Warner Losh wrote:

On Nov 3, 2014, at 11:11 AM, Brooks Harris bro...@edlmax.com
  wrote:


CAUTION about the PTP Epoch. Its not just nitpicking.


...


We've been advised by PTP experts that A) yes, its confusing, and B) most implementations use a integral-second interpretation, 
as in Table B.1. I understand the escape clause they use to justify this is the (POSIX) algorithms phrase 
in Note 1 of 7.2.2 Epoch. By (POSIX) algorithms they mean gmtime() and (strict) POSIX ticks 
at 1Hz, so, integral seconds. In any event its really the only interpretation that yields a manageable, practical, implementation 
that is consistent with TAI and UTC, NTP, and common-use of POSIX.


A few years ago, I had to produce TAI-like data from a measurement system. We defined the value as 
seconds since 1970 but the technical definition was number of SI seconds since 1 Jan 
1972 00:00:00 UTC + 10 + #seconds-in-197071 to avoid the ambiguity. Given that our chief 
time scientist suggested this, and they were quite involved in PTP...

I assume you mean number of SI seconds since 1 Jan 1972 00:00:00 UTC + 10 - #seconds-in-197071 ? And 
the #seconds-in-197071 is (2 * 365 * 86400), right? That would be coincident with the PTP Epoch as 
interpreted above, that is, seconds since 1970 (TAI).

TAI is ahead of UTC, so you have to add in the leap seconds to UTC to get TAI. 
At 1 jan 1972 00:00:00 UTC this offset was 10s, exactly. To bias the date back 
to 1970, you have to add in 2 * 365 * 86400, to give a value of 63072010 for 1 
jan 1972 00:00:00 UTC. I don't think you want to subtract it, since that leads 
to an epoch of 31 DEC 1973 00:00:00 due to the leap day in 1972, right?


OH, well, which way round are we calculating? 1972-01-01T00:00:00Z (UTC) 
+ 10 = 1972-01-01 00:00:00 (TAI) - (2 * 365 * 86400) = 1970-01-01 
00:00:00 (TAI) = 1969-12-31T23:59:50Z (proleptic UTC). RIght?


(Of course its just these knids of miscommunications that lead to the 
great confusions and debate over UTC and civil time...)


-Brooks



Warner


-Brooks


Warner





___
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



___
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

Re: [LEAPSECS] the big artillery


On Nov 3, 2014, at 1:37 PM, Brooks Harris bro...@edlmax.com wrote:

 
 
 On 2014-11-03 03:04 PM, Warner Losh wrote:
 On Nov 3, 2014, at 12:53 PM, Brooks Harris bro...@edlmax.com
  wrote:
 
 
 On 2014-11-03 02:19 PM, Warner Losh wrote:
 
 On Nov 3, 2014, at 11:11 AM, Brooks Harris bro...@edlmax.com
 
  wrote:
 
 
 CAUTION about the PTP Epoch. Its not just nitpicking”.
 
 
 ...
 
 
 We've been advised by PTP experts that A) yes, its confusing, and B) most 
 implementations use a integral-second interpretation, as in Table B.1. I 
 understand the escape clause they use to justify this is the (POSIX) 
 algorithms phrase in Note 1 of 7.2.2 Epoch. By (POSIX) algorithms they 
 mean gmtime() and (strict) POSIX ticks at 1Hz, so, integral seconds. 
 In any event its really the only interpretation that yields a manageable, 
 practical, implementation that is consistent with TAI and UTC, NTP, and 
 common-use of POSIX.
 
 
 A few years ago, I had to produce TAI-like data from a measurement system. 
 We defined the value as “seconds since 1970” but the technical definition 
 was number of SI seconds since 1 Jan 1972 00:00:00 UTC + 10 + 
 #seconds-in-197071” to avoid the ambiguity. Given that our chief time 
 scientist suggested this, and they were quite involved in PTP…
 
 I assume you mean number of SI seconds since 1 Jan 1972 00:00:00 UTC + 10 
 - #seconds-in-197071” ? And the #seconds-in-197071” is (2 * 365 * 
 86400), right? That would be coincident with the PTP Epoch as interpreted 
 above, that is, seconds since 1970 (TAI)”.
 
 TAI is ahead of UTC, so you have to add in the leap seconds to UTC to get 
 TAI. At 1 jan 1972 00:00:00 UTC this offset was 10s, exactly. To bias the 
 date back to 1970, you have to add in 2 * 365 * 86400, to give a value of 
 63072010 for 1 jan 1972 00:00:00 UTC. I don’t think you want to subtract it, 
 since that leads to an epoch of 31 DEC 1973 00:00:00 due to the leap day in 
 1972, right?
 
 OH, well, which way round are we calculating? 1972-01-01T00:00:00Z (UTC) + 10 
 = 1972-01-01 00:00:00 (TAI) - (2 * 365 * 86400) = 1970-01-01 00:00:00 (TAI) = 
 1969-12-31T23:59:50Z (proleptic UTC). RIght?
 
 (Of course its just these knids of miscommunications that lead to the great 
 confusions and debate over UTC and civil time...)

I think you have it backwards. If we count the number of SI seconds since 1972, 
then to rebase that count to an epoch of 1970 rather than 1972 we have to add 
in those two years.

Numbers we want at start of:

1970 = 0
1972 = 2 * 365 * 86400 + 10 = 63072010
1980 = 10 * 365 * 86400 + 2 * 86400 + 19 = 315532819

Numbers of SI seconds since the start of 1972:
1972 = 0
1980 = 8 * 365 * 86400 + 2 * 86400 + 9 = 252460809

so to make a count since 1972 into a count since 1970, given these numbers, we 
have to add in 63072010 to the second set. This gives us a pseudo-count of 
seconds since 1970 which is related to the current unix time_t value by adding 
in the number of leap-seconds valid for that number, which is what the PTP 
timescale should give us if you read the standards documents right. And it does 
so w/o the ambiguity of UTC’s rubber seconds and tiny leaps during the 
1970-1972 period.

Warner


signature.asc
Description: Message signed with OpenPGP using GPGMail
___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs

Re: [LEAPSECS] the big artillery

2014-11-03 Thread Dennis Ferguson


On 3 Nov, 2014, at 07:13 , Warner Losh i...@bsdimp.com wrote:
 TAI is a paper clock. You can convert your time stamps you get today from
 your atomic clock to TAI time stamps once the offsets (phase and frequency)
 have been determined for your clock by comparing it to all the others in
 the data that makes up this paper clock. Until then, you can only have
 speculative or preliminary values. For most people, I’ll agree this doesn’t
 matter (+36s or whatever the current offset is). For some it is quite 
 important.
 
 UTC is also a paper clock. However, this paper clock has actual clocks that
 are tightly steered to it that people can exchange time with to steer their 
 clocks
 to it. That’s why the recommendations are to use UTC time.

?? UTC is defined by an integer relationship (the leap second count) to TAI.
That's an exact, defined relationship; it is perfect by definition.  The
clocks that produce UTC are the same clocks that produce TAI.  A clock that
is steered to UTC is also being steered to TAI (less an integer number of
seconds).  If you know UTC with some precision, and you know the current
value of the integer, you know TAI with the same precision.  This isn't like
the relationship between, say, TT and TAI, which is a nominal constant but
which can in fact vary a bit (by the defects in the realization of TAI) since
TT has its own physical definition while TAI incorporates its own defects.
UTC also incorporates TAI's defects.  If you know UTC and you know the
integer there is no way to not know TAI.

I think the real issue relates to the criteria used for the design of UTC.
Steve Allen listed two of them from an ITU document but the paper by Essen
here

http://www.leapsecond.com/history/1968-Metrologia-v4-n4-Essen.pdf

includes the third in section 4.  Cutting and pasting:

   Atomic time has been introduced into time signal services with the
   following aims in mind:

 a) To make the full accuracy of the atomic clock widely and immediately
available.
 b) To avoid confusion by having two separate systems of time signals.
 c) To maintain the time scale made available by the signals sufficiently
near to UT2 for navigators who might not have ready access to
published corrections.

b) is the problem.  The idea is that everyone, everywhere, who transmits
time signals should transmit the same time scale so that, which ever source
you use, you get the same time with no ambiguity about what time that is.
This doesn't deny the plethora of other technical timescales which are
used, but providing these is supposed to be by done by expressing their
relationship to the one that is transmitted (published corrections) so
that we end up with a system where just one timescale is distributed
and everything else is determined by its relationship to that.

From the little I know they still take this design very seriously.
This means that every use of a timescale other than UTC for transferring
time is really considered to be a failure of UTC.  GPS time is a
failure, Beidou time is a failure and any use of TAI for time
distribution is a failure.  There is no reason you can't distribute
time in TAI, they just don't want you to do it and maybe have some
good reasons for that.

There is some clear evidence that their concerns about having more than
one timescale distributed are well founded, e.g. Android phones on some
networks with clocks which were once 15 seconds off.  There is also
some very clear evidence, however, that UTC as it is defined now is
not right for the purpose, e.g. GLONASS which did the right thing
by using UTC as its system timescale and then suffered leapsecond
failures, and the recurring problems with NTP implementations.

I am old enough to have worked on ntpd when this one timescale
system still worked (as in, they could force it down your throat
whether you liked it or not, not as in, the software actually
worked).  In the late 1980's and early 1990's you could plug in a
radio clock and get quite good UTC, but the integer relationship
to TAI was harder to come by since it wasn't transmitted by the
radio services and the Internet wasn't a given then.  It would
have been hard to pick TAI, or anything other than UTC, as your
distribution timescale since nothing else was as reliably available.
When they told you don't use TAI, we don't distribute it they were
telling you the truth.  This changed only when they allowed civilian
access to GPS, the original failure, since then determining TAI was
trivial via a defined constant while UTC was the one that required
some work. Now, when they tell you we don't distribute TAI, it is
quite reasonable to wonder just what the heck they are talking about.

I personally believe that that the design goal of having one
common timescale distributed is quite vital, that we would
probably come to regret doing anything else and that if you
choose TAI for your distribution timescale you are probably
making a mistake.  On the

Re: [LEAPSECS] the big artillery


On Nov 3, 2014, at 3:03 PM, Dennis Ferguson dennis.c.fergu...@gmail.com wrote:

 
 On 3 Nov, 2014, at 07:13 , Warner Losh i...@bsdimp.com wrote:
 TAI is a paper clock. You can convert your time stamps you get today from
 your atomic clock to TAI time stamps once the offsets (phase and frequency)
 have been determined for your clock by comparing it to all the others in
 the data that makes up this paper clock. Until then, you can only have
 speculative or preliminary values. For most people, I’ll agree this doesn’t
 matter (+36s or whatever the current offset is). For some it is quite 
 important.
 
 UTC is also a paper clock. However, this paper clock has actual clocks that
 are tightly steered to it that people can exchange time with to steer their 
 clocks
 to it. That’s why the recommendations are to use UTC time.
 
 ?? UTC is defined by an integer relationship (the leap second count) to TAI.
 That's an exact, defined relationship; it is perfect by definition.  The
 clocks that produce UTC are the same clocks that produce TAI.  A clock that
 is steered to UTC is also being steered to TAI (less an integer number of
 seconds).  If you know UTC with some precision, and you know the current
 value of the integer, you know TAI with the same precision.  This isn't like
 the relationship between, say, TT and TAI, which is a nominal constant but
 which can in fact vary a bit (by the defects in the realization of TAI) since
 TT has its own physical definition while TAI incorporates its own defects.
 UTC also incorporates TAI's defects.  If you know UTC and you know the
 integer there is no way to not know TAI.

I think there’s an ambiguity in the language, and perhaps I’m splitting too 
fine a hair.

UTC(foo) is generated by the foo national labs based on steering an ensemble of 
clocks to what they thing UTC should be. I believe that makes it a paper clock, 
since it is a signal generated and steered to a number of source clocks. My 
understanding of the term, though, is based on engineering computer systems to 
steer and measure clocks, not on a PhD. Users can only get UTC(foo) or a signal 
derived from UTC(foo) (e.g., traceable to NIST) and never UTC itself. Of course 
they can get to a putative TAI(foo) trivially (I say putative, because as far 
as I know, no lab generates TAI synchronized signals for reasons you go into). 
However, they cannot get back to TAI(BIPM), which never generated in real time, 
but only computed after the fact when the various foos that create UTC(foo) and 
measure against each other report their measurements to BIPM. The national labs 
then use this data to steer their UTC(foo) signals to more closely match the 
presumed evolution of TAI(BIPM).

That’s the hair I’m trying to split. Sorry if this was ambiguous, but when 
recovering time signals, the source is important. I believe I even said for 
most users this difference won’t matter. This difference, though, is one of the 
reasons I think that use of TAI is strongly discouraged, but I have no 
documentation to back this up. Only engineering experience and reading the tea 
leaves of many of the statements that Steve Allen has dug up.

 I think the real issue relates to the criteria used for the design of UTC.
 Steve Allen listed two of them from an ITU document but the paper by Essen
 here
 
http://www.leapsecond.com/history/1968-Metrologia-v4-n4-Essen.pdf
 
 includes the third in section 4.  Cutting and pasting:
 
   Atomic time has been introduced into time signal services with the
   following aims in mind:
 
 a) To make the full accuracy of the atomic clock widely and immediately
available.
 b) To avoid confusion by having two separate systems of time signals.
 c) To maintain the time scale made available by the signals sufficiently
near to UT2 for navigators who might not have ready access to
published corrections.
 
 b) is the problem.  The idea is that everyone, everywhere, who transmits
 time signals should transmit the same time scale so that, which ever source
 you use, you get the same time with no ambiguity about what time that is.
 This doesn't deny the plethora of other technical timescales which are
 used, but providing these is supposed to be by done by expressing their
 relationship to the one that is transmitted (published corrections) so
 that we end up with a system where just one timescale is distributed
 and everything else is determined by its relationship to that.

Strong agreement that (b) is the problem. Also agree with your conclusion below.

 From the little I know they still take this design very seriously.
 This means that every use of a timescale other than UTC for transferring
 time is really considered to be a failure of UTC.  GPS time is a
 failure, Beidou time is a failure and any use of TAI for time
 distribution is a failure.  There is no reason you can't distribute
 time in TAI, they just don't want you to do it and maybe have some
 good reasons for

Re: [LEAPSECS] the big artillery