On Jan 12, 2015, at 2:53 PM, Martin Burnicki
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 both leap second info as w
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 a
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 "
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.
ftp://hpiers.obspm.fr/iers/bul/bulc/
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
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 i
> 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 understa
> 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"
- Down
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 Novem
> 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
> Meta
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 su
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 wo
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 fi
On Sun, 11 Jan 2015 23:58:08 -0800
"Tom Van Baak" 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 given UTC dat
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 December
Steve Allen writes:
> On Sat 2015-01-10T22:53:14 -0800, Ask Bj=F8rn Hansen hath writ:
> > What's better about NTP and the NTP Pool since 2012?
>
> This is a question better answered by David Malone based on his
> long-term monitoring of the leap flags in the NTP pool, but ...
>
> At the end of 20
16 matches
Mail list logo
