On Sun, 31 Dec 2006, Rob Seaman wrote:
>
> But actually, I think we should call leap seconds what they are -
> intercalary events.
Yes! I also liked Zefram's comment "As a calendar, UTC is presently of the
observational variety."
http://www.mail-archive.com/leapsecs@rom.usno.navy.mil/msg01367.htm
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
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
Magnus Danielson wrote:
>TA(GPS) = GPS + 19 + C0
No, there is no TA(GPS). TA(k) are distinct timescales that AFAICT
generally do not attempt to track TAI. Presumably they are intended as
maximally stable frequency standards, not steering to maintain long-term
interval accuracy, like TAI itself.
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
TAI(GP
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. T
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 in the time community to call something without
> leap seconds "TAI" or "TAI + fixed offset". TAI means something very
> specific. That's the other
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 b
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
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 tedi
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 an
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: http://domains.dan.inf
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 p
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
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 th
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
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 many
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 devic
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,
Poul-Henning Kamp wrote:
>By extension, that is why most calendar reform proprosals fall flat
>before they even get talked about: they tinker with details. If
>you want to reform calendars, do something radical so that people
>can see the difference clearly.
I wonder if this is why TAI hasn't cau
In message: <[EMAIL PROTECTED]>
Ashley Yakeley <[EMAIL PROTECTED]> writes:
: 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.
In message <[EMAIL PROTECTED]>, Tony Fin
ch writes:
>Good call. I have found that keeping my watch on GMT worked quite well
>when I was in San Francisco and regularly communicating with people in the
>UK, but when I moved back to Cambridge a GMT watch during BST was similar
>yet wrong enough to be
On Tue, 2 Jan 2007, Zefram wrote:
>
> Same for years too: the Roman calendar was naturally arranged so
> that the annual period of growing and harvesting things was entirely
> encompassed by the calendar year. Imagine how annoying it would be if the
> summer overlapped the legal year end. Oh, wai
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
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 k
> > 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)
John Cowan wrote:
>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
>midnight.
Same for years too: the Roman calendar was naturally arranged so
that the annual period of growing and harvesting things was e
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 polyno
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
mid
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
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.
Thi
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
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 a
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
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, interva
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
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 n
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
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
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]>, Steve Allen writes:
>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
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 in
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. And
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
: > > t
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 UTC seconds.
>
> Not if you include the timezone offset in the representation.
Qu
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 a
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 PROTEC
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 arrhythmi
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
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 or do-
>overs.
Rob, If y
M. Warner Losh scripsit:
> Well, if you count the variable radix notation as being 'continuous'
> then maybe you are right. However, you never know when the radix is
> variable, hence the assertion on many people's part that UTC is
> discontinuous.
Indeed, one could say that *every* minute that
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'
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 t
Hi Folks,
I've been lurking for a while and I'd like to add my thoughts. Whilst I'm a
professional software engineer (and was very active during the y2k "bug") I
also am an amateur astronomer, and one could call me a time nut - my wife
certainly does. I have built a GPS disciplined oscillator a
54 matches
Mail list logo
