I realized I hadn't updated the printed header:
Domain Name IPv4 DecodedFlags
bulletin-c.leapsec.com - 250.10.36.152 - OK 2015 7 36 1 (1, 0)
Yes, there have been bugs (and shortcomings, or at least trade-offs)
with leapsecond propagation in the NTP codebase over the decades.
Upgrading software is a good thing.
That can be ancient release + patches or current supported software
that has patches.
Please see
The marketplace.org article quotes Bob Tjoelker as saying his team, and
deep-space missions in general, can handle leap seconds. I've known Bob
Tjoelker for years. He's a super-scientist designing super-clocks. Since
some of those clocks are space-qualified, he is literally a rocket
On Jan 26, 2015, at 11:58 PM, Hal Murray hmur...@megapathdsl.net wrote:
If Bulletin C contained a table of leap seconds for the next 6*N (for
hopefully large values of N), a significant hassle to leap second
implementation could be avoided as 6*N would approach the useful life of an
On 27 January 2015 at 23:03, Warner Losh i...@bsdimp.com wrote:
...
A cold spare that's sitting on the shelf powered off for more than 6
months. When
the original fails, the hot spare is returned to service and must wait an
additional ~30
minutes to get the latest almanac before it can recover
On Jan 27, 2015, at 4:15 PM, Peter Vince petervince1...@gmail.com wrote:
On 27 January 2015 at 23:03, Warner Losh i...@bsdimp.com wrote:
...
A “cold spare” that’s sitting on the shelf powered off for more than 6
months. When
the original fails, the hot spare is returned to service
Harlan,
Harlan Stenn wrote:
Yes, there have been bugs (and shortcomings, or at least trade-offs)
with leapsecond propagation in the NTP codebase over the decades.
Upgrading software is a good thing.
That can be ancient release + patches or current supported software
that has patches.
Please
Tom Van Baak wrote:
The truncated week numbers are a good source for potential errors
I agree, but...
If the current week number is off by more than +-127 then this is ambiguous.
No, it's not ambiguous, it was just a Motorola bug. The wrap is in the spec and
there's no problem with that.
Brooks Harris bro...@edlmax.com wrote:
Agreed. Its really easier to implement end of (any) month. Checking for June
and December just risks bugs and is not comprehensive anyway.
But there have been real bugs due to leap indicators remaining set too
long, leading to bogus leaps at the end of
Tim Shepard wrote:
While you're at it, make sure the words June and December are also never written into the standard.
Only IERS gets to pick the month, and everyone one else follows what they tell us. That goes for
code, tables, scripts, standards, man pages, etc. We can assume with
But there have been real bugs due to leap indicators remaining set too
long, leading to bogus leaps at the end of July. So in practice there is
less risk in allowing leaps only in June and December.
Those real bugs are better fixed at their source than worked around in this
manner. Ok, easy
On Jan 27, 2015, at 8:47 PM, Tim Shepard s...@alum.mit.edu wrote:
If Bulletin C contained a table of leap seconds for the next 6*N (for
hopefully large values of N), a significant hassle to leap second
implementation could be avoided as 6*N would approach the useful life of an
embedded
On Jan 27, 2015, at 9:03 PM, Steve Allen s...@ucolick.org wrote:
On Tue 2015-01-27T22:47:48 -0500, Tim Shepard hath writ:
Why does such a system need to know what time it is UTC?
For some devices I would expect it is because of statutory or
regulatory requirements which require that it
The European CEPT Electronic Communications Committee
ruminates on the leap second situation at ITU-R WRC-15
http://apps.ero.dk/eccnews/jan-2015/wrc-15-universal-time.html
--
Steve Allen s...@ucolick.orgWGS-84 (GPS)
UCO/Lick Observatory--ISB Natural Sciences II,
Tom and I seem to keep the same (early) hours...
On Jan 27, 2015, at 4:49 AM, Tom Van Baak t...@leapsecond.com wrote:
But there have been real bugs due to leap indicators remaining set too
long, leading to bogus leaps at the end of July. So in practice there is
less risk in allowing leaps
Tom Van Baak wrote:
But there have been real bugs due to leap indicators remaining set too
long, leading to bogus leaps at the end of July. So in practice there is
less risk in allowing leaps only in June and December.
Those real bugs are better fixed at their source than worked around in this
Rob Seaman sea...@noao.edu wrote:
The issue is policy versus implementation. The standard allows the end
of every month, so any implementation (whether DNS or otherwise) should
do likewise. The IERS June / December policy is appropriate for the
current epoch - i.e., oversamples the UTC
The truncated week numbers are a good source for potential errors
I agree, but...
If the current week number is off by more than +-127 then this is ambiguous.
No, it's not ambiguous, it was just a Motorola bug. The wrap is in the spec and
there's no problem with that. In fact, in 2003
If the current week number is off by more than +-127 then this is
ambiguous. This has rolled over several time in the period where no leap
second had been scheduled for 7 years, and all the time the 8 bit week
number of the last recent leap second was broadcast.
Yes, see
On Tue 2015-01-27T22:47:48 -0500, Tim Shepard hath writ:
Why does such a system need to know what time it is UTC?
For some devices I would expect it is because of statutory or
regulatory requirements which require that it should do so.
Not everyone feels able to take the course of GPS, Galileo,
If Bulletin C contained a table of leap seconds for the next 6*N (for
hopefully large values of N), a significant hassle to leap second
implementation could be avoided as 6*N would approach the useful life of an
embedded system for relatively small values of N and the embedded system
On Tue 2015-01-27T21:41:17 +, Matsakis, Demetrios hath writ:
Equally unfortunate is that 30 servers in the NTP pool inserted a
leap second last Dec 31.
There is no action that the ITU-R can take which will change this kind
of misbehavior in these already-deployed systems.
Therefore this is
On Jan 27, 2015, at 7:18 PM, Steve Allen s...@ucolick.org wrote:
On Tue 2015-01-27T21:41:17 +, Matsakis, Demetrios hath writ:
Equally unfortunate is that 30 servers in the NTP pool inserted a
leap second last Dec 31.
There is no action that the ITU-R can take which will change this
On Tue 2015-01-27T20:19:14 -0700, Warner Losh hath writ:
By comparison, the list of mistaken leap second issues is legion
Isn't that relevant to the practicability of any standard under
discussion? Or am I missing your point?
Regulatory action saying that there will be no more leap seconds in
24 matches
Mail list logo
