I find it remarkable that one group of time users chose a
particular time dissemination mode (GPS) and made the typical
array of poor decisions / errors with software. They also
create a rather arbitrary demand of obtaining correct UTC
within 5 minutes of installing hardware that has been
sitting
In message: 1ebbf6bd136d4b7aa983517fc850e...@grendel
Gerard Ashton ashto...@comcast.net writes:
: I find it remarkable that one group of time users chose a
: particular time dissemination mode (GPS) and made the typical
: array of poor decisions / errors with software. They also
:
In message 4ac87da2.4040...@rubidium.dyndns.org, Magnus Danielson writes:
Of course it cannot output a correct UTC solution until it has received
page 18 subframe 4, but it can store the leapsecond offset in
non-volatile RAM since last lock and for most of times that would give
correct UTC
Poul-Henning Kamp wrote:
In message 4ac87da2.4040...@rubidium.dyndns.org, Magnus Danielson writes:
Of course it cannot output a correct UTC solution until it has received
page 18 subframe 4, but it can store the leapsecond offset in
non-volatile RAM since last lock and for most of times that
In message 4ac88906.30...@rubidium.dyndns.org, Magnus Danielson writes:
Poul-Henning Kamp wrote:
most of the times is simply not good enough.
Then you haven't understood the limits. GPS itself only works most of
the times.
The difference is, when GPS does not work, the receiver goes out of
Poul-Henning Kamp wrote:
In message 4ac88906.30...@rubidium.dyndns.org, Magnus Danielson writes:
Poul-Henning Kamp wrote:
most of the times is simply not good enough.
Then you haven't understood the limits. GPS itself only works most of
the times.
The difference is, when GPS does not
Poul-Henning Kamp said:
Using a GPS-UTC delta from memory, before we have an updated value
from the sats is just plain old bogusly wrong.
Disagree.
I've got a GPS receiver here. It reports UTC so, I presume, uses a stored
delta until it picks up a new one. For the uses I have for it, an error
It all depends on your application. If you are controlling Loran C
signals, no data is better. The Loran stations cant broadcast the
wrong tomr and have some heuristics that make it a painful operation
to restart. High power transmitters are like that. Likewise for a
stratum 1 ntp
In message 20091004141116.gl90...@davros.org, Clive D.W. Feather writes:
Poul-Henning Kamp said:
Using a GPS-UTC delta from memory, before we have an updated value
from the sats is just plain old bogusly wrong.
Disagree.
I've got a GPS receiver here. It reports UTC so, I presume, uses a stored
In message: 4ac732c8.3060...@rubidium.dyndns.org
Magnus Danielson mag...@rubidium.dyndns.org writes:
: Poul-Henning Kamp wrote:
: In message 1254164464.4ac107f021...@webmail.unb.ca, Richard B. Langley
writ
: es:
: http://gauss.gge.unb.ca/ITU_future_UTC_(CGSIC_49th).pdf
:
:
Tried sending a copy of Ron Beard's viewgraphs as it might be some time before
they show
up on the Coast Guard web site but the message is held up awaiting moderator
approval.
Here is a link to them instead
http://gauss.gge.unb.ca/ITU_future_UTC_(CGSIC_49th).ppt.
-- Richard Langley
Quoting
In message 1254159223.4ac0f37727...@webmail.unb.ca, Richard B. Langley writ
es:
Tried sending a copy of Ron Beard's viewgraphs as it might be some time before
they show
up on the Coast Guard web site but the message is held up awaiting moderator
approval.
Here is a link to them instead
Any
In message 1254164464.4ac107f021...@webmail.unb.ca, Richard B. Langley writ
es:
http://gauss.gge.unb.ca/ITU_future_UTC_(CGSIC_49th).pdf
Thanks.
Although I do appreciate what the context conveys, I did smile when I
noticed that the last slide mentions GPS time but ends with
Only UTC can be
http://www.gpsworld.com/gnss-system/cgsic-%E2%80%93-the-rest-better-late-never-8956
-- Richard Langley
Quoting Richard B. Langley l...@unb.ca:
There will likely be a report on anything significant at the CGSIC meeting in
Savannah
the week after next
In message ab352dd8-ffdb-4ccf-a582-c7db12163...@noao.edu, Rob Seaman writes:
I have (tediously, bombastically, endlessly) asserted that civil time
IS solar time. This is a statement of requirements. Requirements
describe the problem space.
And you have repeatedly tried to ignore the
Poul-Henning Kamp wrote:
And you have repeatedly tried to ignore the question of how large
the civil-solar tolerance is, can or should be.
I don't think a fair and impartial witness would say given my plethora
of messages over the years that I've ever successfully ignored
anything :-)
Tony Finch wrote:
India is a prominent example of a half hour timezone offset.
(Sorry for straying off topic.)
Indeed. I reset the second clock on my phone to the timezone of New
Delhi when my daughter had a semester in Dharamsala. It's been a
couple of years and I've never set it
Richard B. Langley wrote:
Quoting Rob Seaman sea...@noao.edu:
It's impressive that civil GPS discussions reach back through so
many meetings. Any idea when the 1st CGSIC meeting was held?
Probably 1986:
Cool. Thanks!
Proceedings of the 1991 National Technical Meeting of the Institute
On Thu, 10 Sep 2009, Rob Seaman wrote:
It is precisely the fact of a international civil timescale that makes the
timezone system work.
Yes.
In return, the many timezones and numerous special cases represent
constraints on the common underlying standard to better track mean solar
time.
M. Warner Losh wrote:
There are a number of solutions to the current leap-seconds problems
that don't completely decouple UTC from the sun.
As well as non-solutions like leap-hours that don't actually eliminate
leap-seconds, but rather accumulate them for later release in one
colossally
In message: de4e112b-d8da-4e92-9458-ea89c8dbc...@noao.edu
Rob Seaman sea...@noao.edu writes:
: M. Warner Losh wrote:
:
: There are a number of solutions to the current leap-seconds problems
: that don't completely decouple UTC from the sun.
:
: As well as non-solutions like
On Wed 2009-09-09T23:49:42 +, Poul-Henning Kamp hath writ:
In message e44632d3-66d3-47d3-8b7a-7d8e7245d...@noao.edu, Rob Seaman writes:
Why leap seconds are difficult to get right for an equipment vendor
Sam Stein, Symmetricom, Inc.
I hope the presentations will be posted online.
:
[LEAPSECS] it's WP7A week in Geneva
Sent by:
leapsecs-boun...@leapsecond.com
The WP7A is meeting in Geneva this week.
There are two documents about UTC on their table as seen here
http://www.itu.int/md/R07-WP7A-C/en
one from People's Republic of China,
and another from BIPM (which
On Tue 2009-09-08T18:39:31 -0700, Steve Allen hath writ:
The WP7A is meeting in Geneva this week.
There are two documents about UTC on their table as seen here
http://www.itu.int/md/R07-WP7A-C/en
one from People's Republic of China,
and another from BIPM (which, curiously, is not about
In message: 20090909172025.gm21...@ucolick.org
Steve Allen s...@ucolick.org writes:
: On Tue 2009-09-08T18:39:31 -0700, Steve Allen hath writ:
: The WP7A is meeting in Geneva this week.
:
: There are two documents about UTC on their table as seen here
:
There will likely be a report on anything significant at the CGSIC meeting in
Savannah
the week after next
http://www.navcen.uscg.gov/cgsic/meetings/49thmeeting/49th_CGSIC_Meeting_Agenda.htm.
-- Richard Langley
Quoting M. Warner Losh i...@bsdimp.com:
In message:
In message: e44632d3-66d3-47d3-8b7a-7d8e7245d...@noao.edu
Rob Seaman sea...@noao.edu writes:
: I'm sensitive (really) to the concerns expressed in the title of this
: talk:
: Why leap seconds are difficult to get right for an equipment vendor �
: Sam Stein, Symmetricom, Inc.
The WP7A is meeting in Geneva this week.
There are two documents about UTC on their table as seen here
http://www.itu.int/md/R07-WP7A-C/en
one from People's Republic of China,
and another from BIPM (which, curiously, is not about question 236/7)
This should be interesting.
--
Steve Allen
28 matches
Mail list logo
