Daniel R. Tobias wrote:
It's a few seconds off from TAI, isn't it? It was synchronized to
UTC in 1980 (I think),
Yes. The epoch for GPS time is 1980-01-06T00:00:00 UTC, which is
1980-01-06T00:00:00 GPS time. Not having leap seconds, it effectively
tracks TAI, with the equation
In message [EMAIL PROTECTED], Zefram writes:
Would have been nice. Actually, since the only real significance of
GPS time is that it's part of the signal format, they could just as
well have picked an unconventional but space-efficient encoding (say,
32-bit count of seconds, wrapping every 4
On Tue, 2 Jan 2007, Steve Allen wrote:
And, yes, explaining all this is very hard. It's not obvious to the
geek that the political and funding realities are more real than the
underlying physics, but that's the way the world works.
I've been reading The Measurement of Time by Audoin and
Ashley Yakeley wrote:
I'd like to see an elastic civil second to which SI nanoseconds are
added or removed. Perhaps this could be done annually: at the
beginning of 2008, the length of the civil second for the year 2009
would be set, with the goal of approaching DUT=0 at the end of 2009.
This was
Zefram wrote:
...
The historical trend is towards using uniform time units. It seems
curious now that when the atomic clock was invented astronomers opposed
calling it a time standard.
Well, it seems curious to everybody except Rob Seaman :-)
...
It is much like the ancient Egyptians (IIRC)
Zefram scripsit:
Projecting into the future, one can foresee the eventual abandonment of
timezones in favour of the universal use of Universal Time.
I think that's over the top. Bureaucratically it is just too annoying
if the large majority of people have a work shift that overlaps legal
On Jan 1, 2007, at 22:56, Steve Allen wrote:
Then let's improve the infrastructure for communicating the best
estimation of earth orientation parameters. Then in a world of
ubiquitous computing anyone who wants to estimate the current
rubber-second-time is free to evaluate the splines or
Then let's improve the infrastructure for communicating the best
estimation of earth orientation parameters. Then in a world of
ubiquitous computing anyone who wants to estimate the current
rubber-second-time is free to evaluate the splines or polynomials
(or whatever is used) and come
On Jan 2, 2007, at 05:15, Zefram wrote:
A technical issue: broadcast time signals are phase-locked with the
carrier, which is at some exact number of hertz. If the time
pulses are
every civil second, and that is now 1.00015 s (as it was in 1961),
it can't be synchronised with the (say) 60
On Jan 2, 2007, at 11:40, Warner Losh wrote:
The second technical problem is that the length of a second is
implicitly encoded in the carrier for many of the longwave time
distribution stations. 10MHz is at SI seconds. For rubber seconds,
the broadcast would drift into adjacent bands reserved
M. Warner Losh wrote:
GPS is also used for UTC today. Many ntpd's are stratum 1 tied to a
GPS receiver.
I imagine two parallel time infrastructures, one synchronised to TAI,
the other to rubber mean universal time. Stratum 0 devices for the
latter would probably have to use radio.
So, sure,
In message [EMAIL PROTECTED], Ashley Yakeley writes:
M. Warner Losh wrote:
GPS is also used for UTC today. Many ntpd's are stratum 1 tied to a
GPS receiver.
I imagine two parallel time infrastructures, one synchronised to TAI,
the other to rubber mean universal time. Stratum 0 devices for the
Magnus Danielson wrote:
The detailed introduction of the frequency
corrections in various sources was different, and getting a coherent view of
where UTC actually where was difficult. Since then we have grown to depend on
UTC transmission to a higher degree than we did back then. Infact, for
From: Ashley Yakeley [EMAIL PROTECTED]
Subject: Re: [LEAPSECS] A lurker surfaces
Date: Tue, 02 Jan 2007 15:21:14 -0800
Message-ID: [EMAIL PROTECTED]
Ashley,
Magnus Danielson wrote:
The detailed introduction of the frequency
corrections in various sources was different, and getting
Magnus Danielson wrote:
The budget isn't there and the govrements already pay
good money for the systems in place and is looking to get as much out of it as
possible.
Yes, you're probably right, they're likely to prefer to patch up
something ultimately broken cheaply than fix it properly.
I
From: Ashley Yakeley [EMAIL PROTECTED]
Subject: Re: [LEAPSECS] A lurker surfaces
Date: Tue, 02 Jan 2007 16:40:23 -0800
Message-ID: [EMAIL PROTECTED]
Ashley,
Magnus Danielson wrote:
The budget isn't there and the govrements already pay
good money for the systems in place and is looking
On 2 Jan 2007 at 12:40, Warner Losh wrote:
The interval math in UTC that's hard today would be significantly
harder with rubber seconds. But it is just software, eh?
In short, it is an interestingly naive idea that was tried in the
1960's and failed when there were only dozens of high
On 2 Jan 2007 at 11:47, Ashley Yakeley wrote:
The obvious solution is to transmit rubber time on a rubber frequency.
Are rubber duckies involved?
--
== Dan ==
Dan's Mail Format Site: http://mailformat.dan.info/
Dan's Web Tips: http://webtips.dan.info/
Dan's Domain Site:
On 2 Jan 2007 at 11:56, Ashley Yakeley wrote:
GPS is TAI. I'm not proposing abandoning TAI for those applications
that need it.
It's a few seconds off from TAI, isn't it? It was synchronized to
UTC in 1980 (I think), but without subsequent leap seconds, so it's
now different from both TAI and
Magnus Danielson wrote:
If you do want a new timescale, I think rubber seconds isn't going
to be the solution.
One might point out that many time scales do rely on rubbery seconds,
e.g., sidereal time and apparent solar time. If might be
enlightening to step back from the tendentious and
In message: [EMAIL PROTECTED]
Daniel R. Tobias [EMAIL PROTECTED] writes:
: On 2 Jan 2007 at 11:56, Ashley Yakeley wrote:
:
: GPS is TAI. I'm not proposing abandoning TAI for those applications
: that need it.
:
: It's a few seconds off from TAI, isn't it? It was synchronized to
:
From: Rob Seaman [EMAIL PROTECTED]
Subject: Re: [LEAPSECS] A lurker surfaces
Date: Tue, 2 Jan 2007 20:45:14 -0700
Message-ID: [EMAIL PROTECTED]
Rob,
Magnus Danielson wrote:
If you do want a new timescale, I think rubber seconds isn't going
to be the solution.
One might point out
From: Steve Allen [EMAIL PROTECTED]
Subject: Re: [LEAPSECS] A lurker surfaces
Date: Tue, 2 Jan 2007 21:35:24 -0800
Message-ID: [EMAIL PROTECTED]
On Tue 2007-01-02T22:16:19 -0700, M. Warner Losh hath writ:
changed in later revisions to be the same as GPS time. There's an
extreme reluctance
On Dec 30, 2006, at 17:41, Jim Palfreyman wrote:
The earlier concept of rubber seconds gives me the creeps and I'm
glad I wasn't old enough to know about it then!
I rather like the idea, though perhaps not quite the same kind of
rubber as was used.
I'd like to see an elastic civil second to
In message: [EMAIL PROTECTED]
Ashley Yakeley [EMAIL PROTECTED] writes:
: Software should serve human needs, not the other
: way around. Anyone needing fixed seconds should use TAI.
I think this idea would be harder to implement than the current
leapseconds.
There are many systems
Ashley Yakeley [EMAIL PROTECTED] wrote:
I'd like to see an elastic civil second to which SI nanoseconds are
added or removed.
Ditto! I have always been in favor of rubber seconds, and specifically
civil second. I believe that the *CIVIL* second should have its own
definition completely and
Michael Sokolov scripsit:
The people who complain about leap seconds screwing up their interval
time computations are usually told to use TAI. They retort that they
need interval time *between civil timestamps*. To me that seems like
what they are really measuring as interval time is not
On Jan 1, 2007, at 17:03, John Cowan wrote:
Michael Sokolov scripsit:
The people who complain about leap seconds screwing up their interval
time computations are usually told to use TAI. They retort that they
need interval time *between civil timestamps*. To me that seems like
what they are
In message: [EMAIL PROTECTED]
[EMAIL PROTECTED] (Michael Sokolov) writes:
: The people who complain about leap seconds screwing up their interval
: time computations are usually told to use TAI. They retort that they
: need interval time *between civil timestamps*.
Actaully, interval
From: Michael Sokolov [EMAIL PROTECTED]
Subject: Re: [LEAPSECS] A lurker surfaces
Date: Mon, 1 Jan 2007 22:22:23 GMT
Message-ID: [EMAIL PROTECTED]
Ashley Yakeley [EMAIL PROTECTED] wrote:
I'd like to see an elastic civil second to which SI nanoseconds are
added or removed.
Ditto! I have
Ashley Yakeley scripsit:
Rubber seconds are appropriate because we have rubber days. People
who need absolute time have their own timescale based on some
absolute unit (the SI second), but to everyone else, the second is
a fraction of the day.
Well, okay. Does the rubberiness go down all
On Tue 2007-01-02T01:48:26 -0500, John Cowan hath writ:
Well, okay. Does the rubberiness go down all the way? Is a civil
nanosecond one-billionth of a civil second, then? If so, how do we
build clocks that measure these intervals?
Let's not.
Let's continue the valid and agreeable notion of
Poul-Henning Kamp wrote:
In message [EMAIL PROTECTED], Rob Seaman writes:
Jim Palfreyman wrote:
Just a reminder that UTC has no - none - nada - discontinuities.
Various computer mis-implementations may, but the standard is very
carefully constructed to avoid spring-forward or fall-back gaps
On Sun 2006-12-31T07:59:35 +, Poul-Henning Kamp hath writ:
Rob, If you feel uncomfortable with calling leapseconds
discontinuities, then we can use the term arrhythmia instead.
The point of my allegory about unplanned pregnancies is that
all practically available time scales have
On Sun, 31 Dec 2006, John Cowan wrote:
However, it's clear that UTC does not contain the sort of jumps
that LCT does, where a single broken-down time may represent
two different UTC seconds.
Not if you include the timezone offset in the representation.
Tony.
--
f.a.n.finch [EMAIL PROTECTED]
Rob Seaman wrote:
Just a reminder that UTC has no - none - nada - discontinuities.
I concur, and so I prefer to say that UTC has _irregularities_. The rest
of what Jim Palfreyman said applies to these irregularities: they must
occur frequently so that the method of handling them is implemented
In message: [EMAIL PROTECTED]
John Cowan [EMAIL PROTECTED] writes:
: Tony Finch scripsit:
: On Sun, 31 Dec 2006, John Cowan wrote:
:
: However, it's clear that UTC does not contain the sort of jumps
: that LCT does, where a single broken-down time may represent
: two different
Poul-Henning Kamp wrote:
Rob, If you feel uncomfortable with calling leapseconds
discontinuities, then we can use the term arrhythmia instead.
Which raises the question of why projects requiring an interval time
scale lacking in such arrhythmias would have selected UTC in the
first place.
In message: [EMAIL PROTECTED]
Rob Seaman [EMAIL PROTECTED] writes:
: Poul-Henning Kamp wrote:
:
: Rob, If you feel uncomfortable with calling leapseconds
: discontinuities, then we can use the term arrhythmia instead.
:
: Which raises the question of why projects requiring an
Jim Palfreyman wrote:
With my time hat on, having time that is discontinuous pains me. It
doesn't make sense in my heart. But at least these
discontinuities are in whole seconds.
Any discontinuities must be regularly done. So they are part of all
computer systems and are tested and used all
In message: [EMAIL PROTECTED]
Rob Seaman [EMAIL PROTECTED] writes:
: Just a reminder that UTC has no - none - nada - discontinuities.
At the very least, the TAI-UTC difference is discontinuous with jumps
at the leap seconds. One could easily suggest that 'UTC has
discontinuities'
41 matches
Mail list logo
