> 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
> wou
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
https://pairlist6.p
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 versi
> On Jan 26, 2015, at 3:03 PM, 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,
>> sta
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 s
> 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 ear
On 2015-01-26 20:05, Brooks Harris wrote:
As a practical matter of modern timekeeping the UTC timescale started at
1972-01-01T00:00:00Z (UTC). NTP, POSIX, 1588/PTP and others refer to epochs and
timescales they call "UTC" that occur earlier than 1972-01-01, so this confuses
matters. But those
> 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
> 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 sure the word "insert" is never used
Thanks, Steve, You're knowledge about the topic is deep and I thank you
for the excellent reports on your pages. Where "UTC" really came from
may become, or may be, a legend. -Brooks
On 2015-01-26 03:39 PM, Steve Allen wrote:
On Mon 2015-01-26T15:05:55 -0500, Brooks Harris hath writ:
Metrolog
On Mon 2015-01-26T15:05:55 -0500, Brooks Harris hath writ:
> Metrologia, 2001, 38, The leap second: its history and possible future
> http://www.cl.cam.ac.uk/~mgk25/time/metrologia-leapsecond.pdf
>
> "The name "Coordinated Universal Time (UTC)" was approved by a
> resolution of IAU Commissions 4 an
On 2015-01-25 03:03 PM, Stephen Scott 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.
As a practical matter of modern timekeeping the UTC timescale started at
1972-01-01T00:00:00Z (UTC). N
On Jan 26, 2015, at 12:21 PM, Warner Losh 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 mention is made
> On Jan 26, 2015, at 9:00 AM, G Ashton 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
> general. So, for
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
general. So, for example, I wouldn't take their choice of midnight to divide
ISO 8601 defines for its purposes midnight as the start of the new day (and
end of the old day). But that does mean that since 1582 everyone who uses or
used the Gregorian calendar as their civil calendar has/had also used
midnight to divide days. Such usages may have exist, they just would not be
On Jan 26, 2015, at 5:23 AM, m...@lumieresimaginaire.com wrote:
> Le 26.01.2015 07:00, Rob Seaman a écrit :
>
>> Have also started experimenting with DUT1 encoding, which is some amalgam of
>> the other three bulletins (predictions versus retroactive computations
>> versus severely rounded valu
Tony Finch wrote:
|Steffen Nurpmeso wrote:
|> leap year calculations do not work correctly until the final
|> introduction of the gregorian date, 1582-10-15.
|
|I think that should be "first" - the Julian to Gregorian migration did not
|complete until the 1900s.
Yes the comment indeed cont
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
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
Steffen Nurpmeso wrote:
>
> leap year calculations do not work correctly until the final
> introduction of the gregorian date, 1582-10-15.
I think that should be "first" - the Julian to Gregorian migration did not
complete until the 1900s.
Tony.
--
f.anthony.n.finchhttp://dotat.at/
Hebrides
21 matches
Mail list logo
