Rob Seaman wrote:
Any implementation should support the entire table of leap seconds.
I agree. I'd arrange the DNS mechanism such that the queried domain
name encodes the month, and the resource record just represents the
TAI-UTC difference that applies that month. Leap events are implied by
Tom Van Baak wrote:
There must be thousands of source files with stale leap second tables
...
Is there any solution to this?
For those who think ahead, the obvious solution is that every leap second
table (hard-coded or otherwise) must include data showing the limits of
its validity, and all code
If you are only broadcasting the next or just recently occurred leap second,
you can perhaps leave out the year and just give a month number, which is
understood to be in a -2 .. +10 window around the current month. e.g. if I
read a month number of 12 now I would understand that to mean there
In message alpine.lsu.2.00.1501190940270.23...@hermes-1.csi.cam.ac.uk, Tony F
inch writes:
If you are only broadcasting the next or just recently occurred leap
second,
What I'm doing is really making Bull-C available with a trivial
DNS query.
It is exactly the info from Bull-C I want
I think that Poul-Henning Kamp has had a fantastic idea and
invented a robust protocol that improves the current situation:
. Using DNS gets you caching and time-to-live for any stored
data; this is not only true on the server side, but the
necessary information is transported through to
In message 20150119092237.1ef75406...@ip-64-139-1-69.sjc.megapath.net, Hal Mu
rray writes:
The CRC is there to detect when DNS replies are rewritten to point
everything at captive portals, as is the case on a lot of free WIFI
networks etc.
What do free WIFI portals do with TXT
Warner Losh i...@bsdimp.com wrote:
On Jan 16, 2015, at 3:37 AM, Tony Finch d...@dotat.at wrote:
$ dig +short leapsecond.dotat.at | sed 's/:6:/:06:/' | sort
1972:06:30::23:59:60
….
2012:06:30::23:59:60
2015:06:30::23:59:60
I’m *loving* this.
Glad you like it, but caveat! I am
Harlan Stenn st...@ntp.org wrote:
DNSSEC needs accurate time (just to state what I expect is obvious).
Yes (though in this case accurate means within several minutes of the
correct time).
I need to write up a proper description of my idea for bootstrapping time
and DNSSEC. So far I have only
Poul-Henning Kamp p...@phk.freebsd.dk wrote:
However, I think it is a loosing strategy to send an ever longer
list of addresses, it's only a matter of time before some random
piece of DNS software does something stupid (again).
Yes, the basic response size is 776 bytes so it is likely to have
The CRC is there to detect when DNS replies are rewritten to point
everything at captive portals, as is the case on a lot of free WIFI
networks etc.
What do free WIFI portals do with TXT records?
What do they do with NTP requests?
--
These are my opinions. I hate spam.
In message 4ccfc94d-6324-4a64-87cb-8ea5e9bc0...@bsdimp.com, Warner Losh write
s:
Unless there is an overriding value in efficient encoding,
There is. getaddrinfo(3) is almost always available and works
about as well as any protocol on the internet can work.
Doesn't getaddrinfo
Hello,
oh, you're of course right with anything you say.
I have to clarify one thing however, and that is that
Poul-Henning Kamp p...@phk.freebsd.dk wrote:
|
|In message 20150116205656.in5lwal6%sdao...@yandex.com, Steffen \
|Nurpmeso write
|s:
|I consider it bad style to (1) misuse
In message 20150117192013.zpd8kq7w%sdao...@yandex.com, Steffen Nurpmeso write
s:
moral is the one thing, but what i really had in mind was the
problem with some lawyer getting in touch with the fact that for
six months or even longer some client address is misused by some
protocol.
1.
In message 20150117230303.gj4...@davros.org, Clive D.W. Feather writes:
Steffen Nurpmeso said:
If you have to use DNS, use TXT records.
The problem with using TXT records is getting hold of them.
getaddrinfo(3) is so much more accessible and reliable than any API
to execute a custom
I really like your protocol and am in fact pretty impressed at the
moment (but that may have nothing to do with your design and code,
looking at Python always makes me feel very petty).
Maybe it would be sufficient to start at 2014, which would avoid
counting months of 42 years -- just like you've
On Jan 17, 2015, at 1:51 PM, Steffen Nurpmeso sdao...@yandex.com wrote:
Maybe it would be sufficient to start at 2014, which would avoid counting
months of 42 years
However the data are encoded, stored or retrieved, there will be a concept of
operation that supports a variety of timekeeping
On Sat 2015-01-17T14:55:09 -0700, Rob Seaman hath writ:
However the data are encoded, stored or retrieved, there will be a
concept of operation that supports a variety of timekeeping / calendar
use cases. These surely include historical / retroactive
requirements. Any implementation should
On Fri, Jan 16, 2015 at 10:37:46AM +, Tony Finch wrote:
$ dig +short leapsecond.dotat.at | sed 's/:6:/:06:/' | sort
1972:06:30::23:59:60
...
Love it ;-)
David.
___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
In message 4abdf373-35f8-4dae-8c64-23369dac8...@noao.edu, Rob Seaman writes:
On Jan 17, 2015, at 1:51 PM, Steffen Nurpmeso sdao...@yandex.com wrote:
Maybe it would be sufficient to start at 2014, which would avoid counting
months of 42 years
However the data are encoded, stored or
On Jan 17, 2015, at 4:12 PM, Poul-Henning Kamp p...@phk.freebsd.dk wrote:
If you need the historical information, you can afford the TCP
connection to IERS.
There's also value in implementing a single ICD for all use cases, but point
taken.
I'm focused on how NTP/PTP clients will be able to
I played a bit with the idea this morning, and I think this is how I would
do it:
+---+---+-+-+---+
|1 1 1 1|M M M M M M M M M|L L L L L L L L L|D D|C C C C C C C C|
+---+---+-+-+---+
3 3
In message 89326.1421483...@critter.freebsd.dk, Poul-Henning Kamp writes:
I played a bit with the idea this morning, and I think this is how I would
do it:
+---+---+-+-+---+
|1 1 1 1|M M M M M M M M M|L L L L L L L L L|D D|C C C C C
+---+---+-+-+---+
|1 1 1 1|M M M M M M M M M|L L L L L L L L L|D D|C C C C C C C C|
+---+---+-+-+---+
3 3 2 2 2 2 2 2 2 2 2 2 1 1 1 1 1 1 1 1 1 1
1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6
In message 20150116020949.97531406...@ip-64-139-1-69.sjc.megapath.net, Hal Mu
rray writes:
Is DNS light weight enough that it's not worth the effort to avoid extra
lookups?
Can the DNS TTL be used for that? I'm not a DNS wizard, but I don't think
the data files feeding the current
Speaking of stale information, I am amused by the summary box on the
right-hand side of http://www.bipm.org/en/bipm-services/timescales/
Tony.
--
f.anthony.n.finch d...@dotat.at http://dotat.at/
Shannon, Rockall, Malin: Northwest backing west 6 to gale 8. High becoming
very rough. Squally
$ dig +short leapsecond.dotat.at | sed 's/:6:/:06:/' | sort
1972:06:30::23:59:60
1972:12:31::23:59:60
1973:12:31::23:59:60
1974:12:31::23:59:60
1975:12:31::23:59:60
1976:12:31::23:59:60
1977:12:31::23:59:60
1978:12:31::23:59:60
1979:12:31::23:59:60
1981:06:30::23:59:60
1982:06:30::23:59:60
On Jan 16, 2015, at 3:37 AM, Tony Finch d...@dotat.at wrote:
$ dig +short leapsecond.dotat.at | sed 's/:6:/:06:/' | sort
Stupid sed tricks to be compliant both with extended ISO-8601 and with the end
of any month requirement of TF.460:
% dig +short leapsecond.dotat.at | sed -e
Presumably a negative leap would be denoted ending :58?
Rob
That's a good question, one that most leap second tables (or leap second code,
for that matter) tend to ignore. Your :58 suggestion means his table is not
really a table of leap seconds anymore. Instead its a table of names of the
On Jan 16, 2015, at 3:37 AM, Tony Finch d...@dotat.at wrote:
$ dig +short leapsecond.dotat.at | sed 's/:6:/:06:/' | sort
1972:06:30::23:59:60
….
2012:06:30::23:59:60
2015:06:30::23:59:60
I’m *loving* this.
I think this would make the problem of “these damn NTP servers are lying to
On Jan 16, 2015, at 8:57 AM, Warner Losh i...@bsdimp.com wrote:
I’m *loving* this.
It's a bit of a goof...but that doesn't necessarily invalidate the gimmick.
In fact, you could actually make the lookups easier if you leveraged the
domain
system. month.year.lastsec.utc.int would be the
On Jan 16, 2015, at 10:14 AM, Rob Seaman sea...@noao.edu wrote:
On Jan 16, 2015, at 8:57 AM, Warner Losh i...@bsdimp.com wrote:
I’m *loving* this.
It's a bit of a goof...but that doesn't necessarily invalidate the gimmick.
The IPv6 thing is a bit of a gimmick, and I understood that…
In message alpine.lsu.2.00.1501161037010.23...@hermes-1.csi.cam.ac.uk, Tony F
inch writes:
$ dig +short leapsecond.dotat.at | sed 's/:6:/:06:/' | sort
1972:06:30::23:59:60
1972:12:31::23:59:60
1973:12:31::23:59:60
1974:12:31::23:59:60
[...]
Neat :-)
However, I think it is a
In message 20150116205656.in5lwal6%sdao...@yandex.com, Steffen Nurpmeso write
s:
The IETF should [...]
Don't even get me started on what the IETF should or should not do.
I tried to find out when the last time I thought Good job IETF
and I realized that was s many years ago that it
Poul-Henning Kamp p...@phk.freebsd.dk wrote:
|
|In message alpine.lsu.2.00.1501161037010.23...@hermes-1.csi.cam.ac.uk, \
|Tony F
|inch writes:
|$ dig +short leapsecond.dotat.at | sed 's/:6:/:06:/' | sort
|1972:06:30::23:59:60
|1972:12:31::23:59:60
|1973:12:31::23:59:60
Warner Losh writes:
... Clients can use them to sort out source of truth to determine the
truthiness of a given NTP servers information.
It will also allow you to leverage DNSSEC to get all the security
inherent in that. Oh wait :)
DNSSEC needs accurate time (just to state what I expect is
One question is that surely somebody else must have thought of this
for conveying other sorts of non-DNS community metadata? What
lessons might be learned?
TXT records were popular for Rick-rolling at some point in the past.
The problem with doing a service like this is who you trust.
Warner,
Is this what you meant?
% dig +short jun.2009.leapsec.com txt
2009-06-30T23:59:59Z”
I don’t want to invest the time typing two entries per year for the past four
decades into the rather constrained web interface if this isn’t the concept ;-)
(Hmm…looks like I can
Poul-Henning Kamp p...@phk.freebsd.dk wrote:
|
|In message 20150114180119.qsyo2boz%sdao...@yandex.com, Steffen \
|Nurpmeso write
|s:
||NTP is a much more specialized protocol than DNS and it is blocked
||a lot of places.
|
|So i apologize, such a thing would indeed even be a great
There is no problem if the message is Next leap second is #N at -MM
and after that changes to Next leapsecond is #{N+1} at unknown future
date.
I've seriously been contemplating offering such a service myself in order to
get reliable leap-second info in Ntimed...
Are you talking about
There are at least 2 discussions on various lists I'm on that are
talking about leap-second files.
Recent versions of ntpd will check the leapsecond file's timestamp and
reload the file automatically when it's been updated.
So it should be pretty easy to code up a cron script to check a site for
In message 20150114180119.qsyo2boz%sdao...@yandex.com, Steffen Nurpmeso write
s:
|NTP is a much more specialized protocol than DNS and it is blocked
|a lot of places.
So i apologize, such a thing would indeed even be a great idea,
fetchable via a simple getaddrinfo(3) / dig(1) call
On Wed 2015-01-14T19:53:52 +, Poul-Henning Kamp hath writ:
Plenty of space for the data we need in an IPv4 'A' record, and
a human readable TXT record could supplement that.
All of the leap second information thru history is already
demonstrated via HTTP transport in Ken Murchison's test
Poul-Henning Kamp p...@phk.freebsd.dk wrote:
|
|In message 20150114115758.gvgcdclg%sdao...@yandex.com, Steffen \
|Nurpmeso write
|s:
|Poul-Henning Kamp p...@phk.freebsd.dk wrote:
||
||In message 54b621b5.1080...@rubidium.dyndns.org, Magnus \
||Danielson writes:
||What
In message 20150114115758.gvgcdclg%sdao...@yandex.com, Steffen Nurpmeso write
s:
Poul-Henning Kamp p...@phk.freebsd.dk wrote:
|
|In message 54b621b5.1080...@rubidium.dyndns.org, Magnus Danielson writes:
|
| About one year ago I contacted the folks at IERS and asked them to put
Good work with the IERS folks Martin!
I agree with this approach, it is they way to do the authoritative side
of things. USNO and NIST is at best providing a service in this aspect.
Cheers,
Magnus
On 01/12/2015 10:53 PM, Martin Burnicki wrote:
Brooks Harris wrote:
IERS publishes this -
Magnus Danielson writes:
DNSSEC should be part of a DNS solution for instance.
... and correct time is a requirement for DNSSEC.
H
___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs
Poul-Henning Kamp p...@phk.freebsd.dk wrote:
|
|In message 54b621b5.1080...@rubidium.dyndns.org, Magnus Danielson writes:
|
| About one year ago I contacted the folks at IERS and asked them to put
| an expiration date into their leap second file since the existing one
| didn't have
In message 54b62fd7.4000...@rubidium.dyndns.org, Magnus Danielson writes:
What would be really useful would be if they provided the current
leapsecond count and the date of the next (if known) via DNS.
DNS because it has built in caching and works almost everywhere.
That would be
If I understand the provenance, BIPM is responsible for maintaining atomic
time and TAI, IERS is responsible maintaining for UT1 and Leap Seconds, and
ITU is responsible for time dissemination. Whats not so clear, and it
would be reassuring to know, is how the information is officially
In message AF8BF6DCD7234A3489E799728A5F4D01@pc52, Tom Van Baak writes:
I'm more of a minimalist. Try this 40-line text file instead:
http://maia.usno.navy.mil/ser7/tai-utc.dat
This simple file has been around since the 90's and is always right.
Ehh
It may be in a purely
On Tue 2015-01-13T07:44:42 -0500, Brooks Harris hath writ:
That's what I meant - there needs to be multiple ways, appropriate
to each architecture or purpose, to obtain the information. So,
that's why I suggested it as an API: a clearly defined set of
metadata that could be implemented in
On Jan 13, 2015, at 6:10 AM, Brooks Harris bro...@edlmax.com wrote:
On 2015-01-12 06:42 PM, Rob Seaman wrote:
On Jan 12, 2015, at 2:53 PM, Martin Burnicki martin.burni...@meinberg.de
wrote:
I've suggested at various occasions that the IERS should be the
authoritative source for a leap
Hi Rob,
On 2015-01-12 06:42 PM, Rob Seaman wrote:
On Jan 12, 2015, at 2:53 PM, Martin Burnicki martin.burni...@meinberg.de
wrote:
I've suggested at various occasions that the IERS should be the authoritative
source for a leap second file.
There were discussions at both the 2013 and 2011
On 2015-01-12 02:03 PM, Tom Van Baak wrote:
If would really be good if there was one authoritative soure for this,
and that there was a uniform format. Ideally there would be multiple
ways to access it, via text and binary for different architectures. The
might be thought of as a UTC Metadata
...@noao.edu]
Sent: Tuesday, January 13, 2015 9:20 AM
To: Leap Second Discussion List
Subject: Re: [LEAPSECS] stale leap second information
On Jan 13, 2015, at 6:10 AM, Brooks Harris bro...@edlmax.com wrote:
On 2015-01-12 06:42 PM, Rob Seaman wrote:
On Jan 12, 2015, at 2:53 PM, Martin Burnicki
On 2015-01-13 01:44 PM, Hal Murray wrote:
If I understand the provenance, BIPM is responsible for maintaining atomic
time and TAI, IERS is responsible maintaining for UT1 and Leap Seconds, and
ITU is responsible for time dissemination. Whats not so clear, and it
would be reassuring to know,
Just a few days ago I had to (begrudgingly) hard-code a leap second
table. I set it up so that an obvious warning would be printed any
time the lookup function was called after the last known time of
validity - i.e. it will start printing obnoxious warnings that it's
using stale data after
On Sun, 11 Jan 2015 23:58:08 -0800
Tom Van Baak t...@leapsecond.com wrote:
The web is full of incorrect and outdated leap second information and tables.
Here's one example:
Standards of Fundamental Astronomy
http://www.iausofa.org/2001_0331/Timescales.html
Delta(AT) (=TAI-UTC) for a
On Sun 2015-01-11T23:58:08 -0800, Tom Van Baak hath writ:
The web is full of incorrect and outdated leap second information and tables.
Here's one example:
Here's somewhat scarier example
this one is almost up to date
http://www.nist.gov/pml/div688/grp50/leapsecond.cfm
but this one is also
If would really be good if there was one authoritative soure for this,
and that there was a uniform format. Ideally there would be multiple
ways to access it, via text and binary for different architectures. The
might be thought of as a UTC Metadata API, from which various UTC
Metadata
To be fair, and here I declare myself as an ex-member of the SOFA
board, the software is clearly labelled 2001-03-31 release. That
page is no longer even accessible from the SOFA home page where the
latest release is dated 2014-10-07.
Regards,
Mark Calabretta
Hi Mark,
I understand, but
On Mon 2015-01-12T11:31:32 -0800, Tom Van Baak hath writ:
Let me know if I'm using your most reliable source correctly:
- Go to https://www.iana.org/time-zones
That indicates the most recent official release was 2014j.
There has been no official release yet in 2015 because there
are no
On Mon 2015-01-12T07:10:23 -0800, Steve Allen hath writ:
at the moment the most reliable source
is probably the IANA TimeZone Database
https://www.iana.org/time-zones
That comes with a caveat that it does not instantly respond to the
changes, so the most recent release is 2014j from November.
Find a reliable source, and at the moment the most reliable source
is probably the IANA TimeZone Database
https://www.iana.org/time-zones
Steve,
Let me know if I'm using your most reliable source correctly:
- Go to https://www.iana.org/time-zones
- Read down until Latest version
- Download
On Mon 2015-01-12T12:14:22 -0800, Steve Allen hath writ:
The new version which is in github reads
# Updated through IERS Bulletin C49
# File expires on: 28 December 2015
#
#@ 3660249600
but also, the new version of the NIST leap-seconds.list file which
is included in the
Brooks Harris wrote:
IERS publishes this - Its up to date (includes 2014-07-01) as of today
as I access it (2015-01-12).
http://hpiers.obspm.fr/eoppc/bul/bulc/Leap_Second_History.dat
I'm not sure when it was updated, maybe with their Bullitin C announcement.
Tom Van Baak wrote:
If would really be good if there was one authoritative soure for this,
and that there was a uniform format. Ideally there would be multiple
ways to access it, via text and binary for different architectures. The
might be thought of as a UTC Metadata API, from which various
Tom Van Baak wrote:
Or use this 40-line text file instead:
http://hpiers.obspm.fr/iers/bul/bulc/Leap_Second.dat
The one is nice because it includes a File expires on 31 December 2015 notice.
This in not an optimal solution, yet, since parsing a string like this
can be error prone. The
On Jan 12, 2015, at 2:53 PM, Martin Burnicki martin.burni...@meinberg.de
wrote:
I've suggested at various occasions that the IERS should be the authoritative
source for a leap second file.
There were discussions at both the 2013 and 2011 UTC meetings well-aligned with
what Martin says, for
IERS publishes this - Its up to date (includes 2014-07-01) as of today
as I access it (2015-01-12).
http://hpiers.obspm.fr/eoppc/bul/bulc/Leap_Second_History.dat
I'm not sure when it was updated, maybe with their Bullitin C announcement.
ftp://hpiers.obspm.fr/iers/bul/bulc/bulletinc.dat
If
Opps, sorry, typo - 2015 not 2014 = Its up to date (includes 2015-07-01)
On 2015-01-12 10:33 AM, Brooks Harris wrote:
IERS publishes this - Its up to date (includes 2014-07-01) as of today
as I access it (2015-01-12).
http://hpiers.obspm.fr/eoppc/bul/bulc/Leap_Second_History.dat
I'm not
I was googling for how to precisely set a sidereal pendulum clock to within 10
milliseconds of accuracy and was reminded of a topic I meant to bring up a
while ago.
The web is full of incorrect and outdated leap second information and tables.
Here's one example:
Standards of Fundamental
72 matches
Mail list logo
