On Feb 11, 2015, at 7:08 AM, Rob Seaman sea...@noao.edu wrote:
For my current encoding, PHK's CRC keeps the final octet out of harm's way:
255.255.255.47 - OK 2142 8 127 -1 (1, 1)
As shown, the first three 255s would require a negative leap second at the
end of July 2142 with a
Steve Allen s...@ucolick.org wrote:
|The IANA tzdata now gets the complete leap second history
|information from the file leap-seconds.list that NIST
|has been publishing for the sake of NTP.
|
|The NIST version of that file can be found at
|ftp://time.nist.gov/pub/leap-seconds.list
|The
Hey guys!
I'm fascinated by the discussions to use DNS to deliver leap-second
and Bulletin C data, but this is way beyond my experience, and I don't
understand a lot of what is being said - I wonder if there is a simple
reference I might refer to, specifically:
Class E addresses?
On Wed, Feb 11, 2015 at 11:12 AM, Peter Vince petervince1...@gmail.com wrote:
Class E addresses? Presumeably the first nybble of the 32-bit IP4 address
is an E (1110), ie 224.xxx.xxx.xxx ? Are these reserved in the same way
that 192.168.xxx.xxx and 10.10.xxx.xxx appear to be?
Look at the
Fantastic - thanks guys!
Peter
On 11 February 2015 at 13:11, Zefram zef...@fysh.org wrote:
Peter Vince wrote:
Class E addresses?
IPv4 address space is for some purposes divided into five classes:
class A is 0.0.0.0/1, class B is 128.0.0.0/2, class C is 192.0.0.0/3,
class D is
Peter Vince wrote:
Class E addresses?
IPv4 address space is for some purposes divided into five classes:
class A is 0.0.0.0/1, class B is 128.0.0.0/2, class C is 192.0.0.0/3,
class D is 224.0.0.0/4, and class E is 240.0.0.0/4. Classes A, B, and
C form the unicast address space, originally with
On Feb 10, 2015, at 3:43 PM, Clive D.W. Feather cl...@davros.org wrote:
Zefram said:
My concern is more about the risk of colliding with some other protocol.
The answer is to not pervert A (or AAA) records for a purpose they are not
designed for. Either use TXT records or, even better, make
I'm very much enjoying the dueling perl / python and CRC / SHA competition here
:-)
On Feb 10, 2015, at 9:45 AM, Zefram zef...@fysh.org wrote:
Rob Seaman wrote:
The trouble with encoding dates in the names and interpolating in the
client is that by the time you're done it would have been
Brooks Harris wrote:
Meantime, the epochs of NTP and POSIX are defined in terms of UTC,
but before 1972-01-01T00:00:00Z (UTC). They exist on a timescale I've
been flamed for calling proleptic UTC. This a timescale that
extrapolates the Gregorian calendar counting method *uncompensated
for Leap
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
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
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
Le 26.01.2015 07:00, Rob Seaman a écrit :
snip
Have also started experimenting with DUT1 encoding, which is some
amalgam of the other three bulletins (predictions versus retroactive
computations versus severely rounded values on uneven calendar
gridding). At any rate the 5 decimal places
: Re: [LEAPSECS] Bulletin C and all that
In message 000201d03914$d18751e0$7495f5a0$@comcast.net, G Ashton writes:
Brooks Harris suggested ISO 8601:2004(E), 3.2.1 The Gregorian
calendar as a source about the Gregorian calendar. Thanks for the
suggestion, but I consider ISO 8601
On Jan 26, 2015, at 12:21 PM, Warner Losh i...@bsdimp.com wrote:
It all depends on the data that you are using whether the new day starts at
midnight
or noon. If you are talking to astronomers before the 20th century, chances
are good
it is noon.
Big fan of Patrick O'Brian. Frequent
On Jan 26, 2015, at 9:00 AM, G Ashton ashto...@comcast.net wrote:
ISO 8601 is the normative definition for date or time representations THAT
CLAIM CONFORMANCE TO ISO 8601. I don't believe the standard was written with
a goal of being a general reference work on time and date notation in
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 near-term modest earth
On 2015-01-26 04:34 PM, Tom Van Baak wrote:
I spent many weeks this year frantically trying to head off exactly this
problem in a standards body defining a timing protocol. It had been
written to insert Leap Seconds at midnight, which we know from Rec 460
is not correct.
Brooks,
Please make
When the format has been sorted out I was thinking of having this data (just
the current/upcoming leap second) on leapsecond.pool.ntp.org, leap.ntppool.org
or something similar.
Ask
___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
On 2015-01-26 01:00 AM, Rob Seaman wrote:
At midnight is a flexible enough phrase to also handle a second that
*finishes* being introduced at the stroke of midnight :-)
I'm sure you know this as well as anyone, but I caution about the casual
use of terms this way.
I spent many weeks this
On Jan 26, 2015, at 3:03 PM, Tim Shepard s...@alum.mit.edu 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,
Hi Tom,
In addition to an interesting systems engineering exercise, it’s great to see
this list working together on something :-) In addition to your kind offer,
Tony Finch should be acknowledged for the original IPv6 notion, and PHK for
settling most of the pragmatic issues with an IPv4
As I said, the experiment has just started with DUT1 information.
Hi Rob,
I own dut1.org if you want to use that for a data service. For the past couple
of years it runs a script to return DUT1 values. I also would be willing to
give up leapsecond.org for the same purpose (right now it's just
On 2015-01-25 14:58, Rob Seaman wrote:
Please let me know about typos, suggestions, etc. Needless to say this
remains a prototype.
...
MM before after encoded crc IP Decodedflags
On Sun 2015-01-25T16:57:58 -0500, G Ashton hath writ:
Brooks Harris mentioned, at approximately Sun 1/25/2015 21:02 UT, a
Gregorian timescale. I believe that since in Gregory's time there was no
alternative to making the passage of calendar days agree with the day/night
cycle, we must
On 2015-01-25 10:04 PM, G Ashton wrote:
Brooks Harris suggested ISO 8601:2004(E), 3.2.1 The Gregorian calendar as
a source about the Gregorian calendar. Thanks for the suggestion, but I
consider ISO 8601 to be garbage; it's so bad it makes me dislike the entire
organization.
I have my
On Jan 25, 2015, at 9:57 PM, Warner Losh i...@bsdimp.com wrote:
On Jan 25, 2015, at 6:15 PM, G Ashton ashto...@comcast.net wrote:
Rob Seaman also wrote:
Leap seconds are introduced at midnight UTC, not when TAI modulo 86400
equals zero.
I would think that midnight UTC is the instant
On Jan 25, 2015, at 6:15 PM, G Ashton ashto...@comcast.net wrote:
Rob Seaman also wrote:
Leap seconds are introduced at midnight UTC, not when TAI modulo 86400
equals zero.
I would think that midnight UTC is the instant when the UTC time becomes
00:00:00. I would call the introduced
Brooks Harris mentioned, at approximately Sun 1/25/2015 21:02 UT, a
Gregorian timescale. I believe that since in Gregory's time there was no
alternative to making the passage of calendar days agree with the day/night
cycle, we must understand Gregorian timescale to mean either apparent or
mean
:60
and ended one second later at 00:00:00.
Gerard Ashton
-Original Message-
From: LEAPSECS [mailto:leapsecs-boun...@leapsecond.com] On Behalf Of Rob
Seaman
Sent: Sunday, January 25, 2015 19:26
To: Leap Second Discussion List
Subject: Re: [LEAPSECS] Bulletin C and all that
On Jan 25, 2015
On 2015-01-25 04:57 PM, G Ashton wrote:
Brooks Harris mentioned, at approximately Sun 1/25/2015 21:02 UT, a
Gregorian timescale. I believe that since in Gregory's time there was no
alternative to making the passage of calendar days agree with the day/night
cycle, we must understand Gregorian
On Jan 25, 2015, at 1:03 PM, Stephen Scott stephensc...@videotron.ca wrote:
Since UTC is defined by the IERS before 1972-01-01 beginning_of_utc is not
appropriate.
This is the beginning of integer leap seconds, not UTC.
Contributors to this list can always count on prompt fact checking ;-)
On Sun 2015-01-25T17:25:33 -0700, Rob Seaman hath writ:
Contributors to this list can always count on prompt fact checking ;-)
That said, the IERS came later than that, didn't it?
Yes. Pretty much the whole story of who did what,and who did not do
what, and when is in my web page
: Sunday, January 25, 2015 19:26
To: Leap Second Discussion List
Subject: Re: [LEAPSECS] Bulletin C and all that
On Jan 25, 2015, at 1:03 PM, Stephen Scott stephensc...@videotron.ca
wrote:
Since UTC is defined by the IERS before 1972-01-01 beginning_of_utc is
not appropriate
I agree with Michael.
The (proper) UTC timescale does not exist before 1972-01-01T00:00:00Z
(UTC). That's the beginning of modern (solar) time. There was, or is,
*by definition*, an initial 10 (integral!) second TAI-UTC offset at that
moment. There is no agreed on a term for these initial 10
Brooks Harris suggested ISO 8601:2004(E), 3.2.1 The Gregorian calendar as
a source about the Gregorian calendar. Thanks for the suggestion, but I
consider ISO 8601 to be garbage; it's so bad it makes me dislike the entire
organization.
Gerard Ashton
45 matches
Mail list logo
