The future of UTC
Le 10/08/2011 07:41, Attila Kinali a écrit :
On Fri, 15 Jul 2011 05:57:45 +0000
"Poul-Henning Kamp"phk@phk.freebsd.dk wrote:
Everybody but the time-lords have always been told to stay away from
TAI in the strongest possible terms by said time-lords, who again and
told the world to use UTC.
May i ask what the reason was to stay away from TAI?
I mean, it is obvious (for me) that for any application that needs
a steady, continious and monotone clock that TAI is one of the best
alternatives among all those time standards.
Attila Kinali
There are all manner of time scales , and each has its use so there is
no need to keep away from any. Just pick that which suits your
application. I think that Poul-Henning was just indicating in a humorous
manner his dislike of the unilateral imposition of a non uniform scale,
UTC, as the transmitted time standard. So if you want a uniform scale,
take TAI. You can get TAI from GPS time by adding 19secs. A number of
GPS receivers can be configured to report GPS time rather than UTC.
Attila Kinali wrote:
On Fri, 15 Jul 2011 05:57:45 +0000
"Poul-Henning Kamp"phk@phk.freebsd.dk wrote:
Everybody but the time-lords have always been told to stay away from
TAI in the strongest possible terms by said time-lords, who again and
told the world to use UTC.
May i ask what the reason was to stay away from TAI?
I mean, it is obvious (for me) that for any application that needs
a steady, continious and monotone clock that TAI is one of the best
alternatives among all those time standards.
Attila Kinali
Strictly TAI, as presently realised, is a paper clock that isn't
actually available in real time.
Bruce
On 10/08/11 09:09, cook michael wrote:
Le 10/08/2011 07:41, Attila Kinali a écrit :
On Fri, 15 Jul 2011 05:57:45 +0000
"Poul-Henning Kamp"phk@phk.freebsd.dk wrote:
Everybody but the time-lords have always been told to stay away from
TAI in the strongest possible terms by said time-lords, who again and
told the world to use UTC.
May i ask what the reason was to stay away from TAI?
I mean, it is obvious (for me) that for any application that needs
a steady, continious and monotone clock that TAI is one of the best
alternatives among all those time standards.
Attila Kinali
There are all manner of time scales , and each has its use so there is
no need to keep away from any. Just pick that which suits your
application. I think that Poul-Henning was just indicating in a humorous
manner his dislike of the unilateral imposition of a non uniform scale,
UTC, as the transmitted time standard. So if you want a uniform scale,
take TAI. You can get TAI from GPS time by adding 19secs. A number of
GPS receivers can be configured to report GPS time rather than UTC.
Well, the "ban" on TAI has resulted in several "TAI-like" time-scale,
such as the GPS time-scale (with nominally 18 second GPS-TAI difference
as I recall it). Several such scales has been produced as a result of
the ban. Now there is a drive to turn the UTC into one of those
time-scales too. What is driving the use of such time-scales is however
not political but technical, and it would have been much better if they
would all had been using the TAI scale to start with.
Besides, SMPTE has defined the SMPTE Epoch such that all sample-rates,
carriers etc. for TV and audio had a common phase of 0 degree at
1958-01-01T00:00:00Z, and since then effectively follows TAI.
So, the time-lords will have to come up with a pretty good reason why
one should not use TAI, if handwaving and just saying so is just a poor
excuse. They should be happy that we do not use EAL, which is the
internal time-scale.
Cheers,
Magnus
On 10/08/11 09:16, Bruce Griffiths wrote:
Attila Kinali wrote:
On Fri, 15 Jul 2011 05:57:45 +0000
"Poul-Henning Kamp"phk@phk.freebsd.dk wrote:
Everybody but the time-lords have always been told to stay away from
TAI in the strongest possible terms by said time-lords, who again and
told the world to use UTC.
May i ask what the reason was to stay away from TAI?
I mean, it is obvious (for me) that for any application that needs
a steady, continious and monotone clock that TAI is one of the best
alternatives among all those time standards.
Attila Kinali
Strictly TAI, as presently realised, is a paper clock that isn't
actually available in real time.
This is not entierly true. There are a few national laboratories which
has a local representation of TAI, alongside their UTC. It is handy to
say that TAI is a paper clock, but it is a comparable scale.
Cheers,
Magnus
Magnus Danielson wrote:
On 10/08/11 09:16, Bruce Griffiths wrote:
Attila Kinali wrote:
On Fri, 15 Jul 2011 05:57:45 +0000
"Poul-Henning Kamp"phk@phk.freebsd.dk wrote:
Everybody but the time-lords have always been told to stay away from
TAI in the strongest possible terms by said time-lords, who again and
told the world to use UTC.
May i ask what the reason was to stay away from TAI?
I mean, it is obvious (for me) that for any application that needs
a steady, continious and monotone clock that TAI is one of the best
alternatives among all those time standards.
Attila Kinali
Strictly TAI, as presently realised, is a paper clock that isn't
actually available in real time.
This is not entierly true. There are a few national laboratories which
has a local representation of TAI, alongside their UTC. It is handy to
say that TAI is a paper clock, but it is a comparable scale.
Cheers,
Magnus
These "local'' versions of TAI -TAI(NPL), TAI(NIST) etc, are also paper
ensemble averages and only a coarse approximation of them is available
in real time.
Bruce
In message 4E425909.7050309@xtra.co.nz, Bruce Griffiths writes:
These "local'' versions of TAI -TAI(NPL), TAI(NIST) etc, are also paper
ensemble averages and only a coarse approximation of them is available
in real time.
This argument is pretty vacuous:
UTC is also a paper clock, and the real time approximations of it,
UTC(NPL), UTC(NIST) etc, are exactly as good or bad as their TAI
parallels.
In fact, they are by definition exactly as good or bad, because
UTC is defined as an integral number of seconds offset from TAI.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
phk@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.
On Wed, 10 Aug 2011 19:16:33 +1200
Bruce Griffiths bruce.griffiths@xtra.co.nz wrote:
May i ask what the reason was to stay away from TAI?
I mean, it is obvious (for me) that for any application that needs
a steady, continious and monotone clock that TAI is one of the best
alternatives among all those time standards.
Strictly TAI, as presently realised, is a paper clock that isn't
actually available in real time.
If TAI is a paper clock, what else should be used if a strictly monotone
time scale is needed?
And what makes UTC different from TAI to be a "real clock", as UTC is
derived from TAI by adding leap seconds?
Would a reverse definition of TAI (or rather TAI' ) by using UTC without the
leap seconds be a good enough approximation?
I'm quite sure i'm not the first one asking this question, but i couldn't
find an answer, neither with google nor in the time-nuts archives.
Attila Kinali
--
The trouble with you, Shev, is you don't say anything until you've saved
up a whole truckload of damned heavy brick arguments and then you dump
them all out and never look at the bleeding body mangled beneath the heap
-- Tirin, The Dispossessed, U. Le Guin
Le 10/08/2011 12:55, Attila Kinali a écrit :
If TAI is a paper clock, what else should be used if a strictly monotone
time scale is needed?
Do you have any specific application in mind?
If you need an SI seconds rated scale, then you need something based on
TAI. GPS time has a TAI second rate and is monotonic. But of course you
would need a GPS receiver to access it.
And what makes UTC different from TAI to be a "real clock", as UTC is
derived from TAI by adding leap seconds?
I don't think TAI is any less real than UTC. UTC just happens to be
the international transmitted time scale. TAI is not generally
available, though both GPS time, and UTC have the same rate.
Would a reverse definition of TAI (or rather TAI' ) by using UTC without the
leap seconds be a good enough approximation?
Well, UTC doesn't exist without leap seconds by definition, but if you
only have UTC available to be able to track TAI , then you can recover
the TAI scale by deducting leap seconds.
I'm quite sure i'm not the first one asking this question, but i couldn't
find an answer, neither with google nor in the time-nuts archives.
Attila Kinali
Hi
If you have a time source to work with, generating a different time scale is
just a math problem. In most cases it's not a very complex one (subtract 19
seconds and move on). If you don't have a time source, then generating any
time scale will be a challenge.
Given the low cost of computing gizmos these days, doing the math to come up
with what ever you want is not going to be all that hard or expensive.
Bob
-----Original Message-----
From: time-nuts-bounces@febo.com [mailto:time-nuts-bounces@febo.com] On
Behalf Of cook michael
Sent: Wednesday, August 10, 2011 10:35 AM
To: time-nuts@febo.com
Subject: Re: [time-nuts] Why not TAI?
Le 10/08/2011 12:55, Attila Kinali a écrit :
If TAI is a paper clock, what else should be used if a strictly monotone
time scale is needed?
Do you have any specific application in mind?
If you need an SI seconds rated scale, then you need something based on
TAI. GPS time has a TAI second rate and is monotonic. But of course you
would need a GPS receiver to access it.
And what makes UTC different from TAI to be a "real clock", as UTC is
derived from TAI by adding leap seconds?
I don't think TAI is any less real than UTC. UTC just happens to be
the international transmitted time scale. TAI is not generally
available, though both GPS time, and UTC have the same rate.
Would a reverse definition of TAI (or rather TAI' ) by using UTC without
the
leap seconds be a good enough approximation?
Well, UTC doesn't exist without leap seconds by definition, but if you
only have UTC available to be able to track TAI , then you can recover
the TAI scale by deducting leap seconds.
I'm quite sure i'm not the first one asking this question, but i couldn't
find an answer, neither with google nor in the time-nuts archives.
Attila Kinali
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to
https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
Hi:
A friend has an observatory and needs very precise time. It turns out
that the best way is to command the system to point to some star then
manually move the scope to put the star on the cross hairs. Doing this
a half dozen times and then fitting the data results in the system
knowing the time to maybe a millisecond.
Doing an NTP sync or having a fancy time base in the control computer
can only get within hundreds of a second. Remember that all the
broadcast time signals are to the nearest second but WWV and WWVB send
the tenths of a second offset for astronomical time but using that he
could get to the nearest tenth of a second. But the above procedure
gets him to maybe a millisecond. I say "maybe" because how well the
scope points in terms of arc seconds of angle depends on many factors.
So, maybe if you really want precision time you also need a very good
observatory?
Have Fun,
Brooke Clarke
http://www.PRC68.com
http://www.End2PartyGovernment.com/