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
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
On Jan 24, 2015, at 7:27 AM, Rob Seaman wrote:
> As shown, I think we also want to index TAI-UTC after the leap. This is
> similar to how the IERS table has it, and remaining aligned with that
> resource may be a strong enough argument. (Negative leap seconds would also
> be made pretty obvi
Brooks Harris wrote:
|On 2015-01-23 10:33 AM, Clive D.W. Feather wrote:
|> Steffen Nurpmeso said:
|>>|> Well. PHK follows the IERS format which uses the 1st of the month
|>>|> after the leap second, i.e., the second after the leap occurred.
|>>|
|>>|This is an implementation detail. PHK???
On Jan 24, 2015, at 1:29 AM, Poul-Henning Kamp wrote:
> In message , Tim Shepard writes:
>
>> What should "next.leapsec.com" point at after July 1, 2015 in the few
>> weeks before Bulletin C number 50 is issued?
>
> It should point to C49 until C50 is published.
>
> And I think it should be bu
In message , Tim Shepard writes:
>What should "next.leapsec.com" point at after July 1, 2015 in the few
>weeks before Bulletin C number 50 is issued?
It should point to C49 until C50 is published.
And I think it should be bulletin-c.$domain
--
Poul-Henning Kamp | UNIX since Zilo
Brooks Harris said:
>> No, you need to use a library that's already been written to do the job.
>> Takes 10 seconds or so.
>
> What "library that's already been written to do the job" are you
> referring to, specifically?
I don't know, not having investigated. But if it's that big a deal, I'm
sur
OK, how about next.leapsec.com. is a CNAME record that points at
c49.leapsec.com. and c49.leapsec.com. has the encoded IP address as
you all have already defined to convey the content of Bulletin C
number 49.
Then when Bulletin C number 50 comes out in July we can leave
c49.leapsec.com as it is
On 2015-01-23 10:33 AM, Clive D.W. Feather wrote:
Steffen Nurpmeso said:
|> Well. PHK follows the IERS format which uses the 1st of the month
|> after the leap second, i.e., the second after the leap occurred.
|
|This is an implementation detail. PHK???s choice is as good as the other.
"Poul-Henning Kamp" wrote:
|
|In message <20150123123330.llbzydw5%sdao...@yandex.com>, Steffen \
|Nurpmeso write
|s:
|>|Bulletin C is issued whether or not a leap second occasion \
|>|(currently June and December, but could be any month) corresponds \
|>|to an actual leap second. T
"G Ashton" wrote:
|to test inputs to be sure they are in the domain of the function. I have
|found that many
|published algorithms fail to state the earliest and latest date for which
|they work. Finding out
|will require much more than 10 seconds.
The function that has been stolen via third
In message <20150123213328.wxzt__5o%sdao...@yandex.com>, Steffen Nurpmeso write
s:
>Ok, if the RR is meant as a regular distribution service for the
>IERS information then that would make absolutely sense to me.
The idea was to make sure programs could get hold of the most
recent bulleti
"Clive D.W. Feather" wrote:
|Steffen Nurpmeso said:
|>|> Well. PHK follows the IERS format which uses the 1st of the month
|>|> after the leap second, i.e., the second after the leap occurred.
|>|
|>|This is an implementation detail. PHK???s choice is as good as the other.
|>
|> And i di
Clive D. W. Feather wrote, with respect to conversion between JDN and
Gregorian calendar date,
> >So in order to calculate the
>> actual date where the drift adjustment occurs you have to face a very
> >elaborate conversion.
>No, you need to use a library that's already been written to do the jo
In message <20150123123330.llbzydw5%sdao...@yandex.com>, Steffen Nurpmeso write
s:
> |Bulletin C is issued whether or not a leap second occasion \
> |(currently June and December, but could be any month) corresponds \
> |to an actual leap second. The encoding (as in PHK’s example) \
> |s
Steffen Nurpmeso said:
> |> Well. PHK follows the IERS format which uses the 1st of the month
> |> after the leap second, i.e., the second after the leap occurred.
> |
> |This is an implementation detail. PHK???s choice is as good as the other.
>
> And i disagree with that. The ISO C(99) st
Rob Seaman wrote:
|On Jan 22, 2015, at 3:27 PM, Steffen Nurpmeso wrote:
|> One of them is that the count of months start 2014 not 1972, which
|> extends the representable range of years until 2099.
|
|Prior leap seconds don’t vanish - nor do prior Bulletins C. \
| There certainly may be ret
Rob Seaman wrote:
|On Jan 22, 2015, at 7:47 AM, Steffen Nurpmeso wrote:
|> Rob Seaman wrote:
|>> I think it’s clear that DNS won’t support all leap second \
|>> use cases, but that it may provide a high reliability / \
|>> low latency method for some specific purposes. Here is \
|>> PHK’s
On Jan 22, 2015, at 3:27 PM, Steffen Nurpmeso wrote:
> One of them is that the count of months start 2014 not 1972, which
> extends the representable range of years until 2099.
Prior leap seconds don’t vanish - nor do prior Bulletins C. There certainly
may be retroactive use cases that rely on
i wrote:
|Below a simple C version for the interested. It doesn't iterate
just an update with encode mode and different integer types (and
ooops bug fixes: accept a "0" adjustment and don't print print two
hyphens for negative drifts).
I wonder wether the drift shouldn't be made unsigned.
Juhuuu
On Jan 22, 2015, at 7:47 AM, Steffen Nurpmeso wrote:
> Rob Seaman wrote:
>> I think it’s clear that DNS won’t support all leap second use cases, but
>> that it may provide a high reliability / low latency method for some
>> specific purposes. Here is PHK’s specific example...
>
> Below a sim
Rob Seaman wrote:
|I think it’s clear that DNS won’t support all leap second \
|use cases, but that it may provide a high reliability / low \
|latency method for some specific purposes. Here is PHK’s specific example:
|
| $ dig +short leap.net-tid.dk a | ./leapdecode.py
| 248.40.141.250 ->
I think it’s clear that DNS won’t support all leap second use cases, but that
it may provide a high reliability / low latency method for some specific
purposes. Here is PHK’s specific example:
$ dig +short leap.net-tid.dk a | ./leapdecode.py
248.40.141.250 -> OK 2015 7 +35 +1
23 matches
Mail list logo
