On 10 July 2016 at 00:12, wrote:
> It doesn't help that the POSIX standard doesn't represent leap seconds
> anyplace, so any elapsed time calculation that crosses a leap second
> is guaranteed to be wrong
So how can we solve the problem? Immediately and long term?
a) use UTC or unix time, a
On Sun 2016-07-10T11:27:33 +0300, Saku Ytti hath writ:
> So how can we solve the problem? Immediately and long term?
The ITU-R had the question of leap seconds on their agenda for 14
years and did not come up with an answer. Their 2015 decision was to
drop the question and ask an alphabet soup of
On Sun, 10 Jul 2016, Saku Ytti wrote:
On 10 July 2016 at 00:12, wrote:
It doesn't help that the POSIX standard doesn't represent leap seconds
anyplace, so any elapsed time calculation that crosses a leap second
is guaranteed to be wrong
So how can we solve the problem? Immediately and l
- Original Message -
> From: "Andrew Gallo"
> Looks like we'll have another second in 2016:
> http://www.space.com/33361-leap-second-2016-atomic-clocks.html
"5... 4... 3... 2... 1... Zero!... Happy New Year!"
But only if you're in London. 7pm EDT.
Cheers,
-- jr 'not on my birthday, da
- Original Message -
> From: "Chris Adams"
> Once upon a time, Patrick W. Gilmore said:
>> But time _DOES_ flow. The seconds count
>> 58, 59, 60, 00, 01, …
>> If you can’t keep up, that’s not UTC’s fault.
[ ... ]
> Leap second handling code is not well-tested and is an ultimate co
On Sun, Jul 10, 2016 at 3:27 AM, Saku Ytti wrote:
[snip]
> a) use UTC or unix time, and accept that code is broken
[snip]
The Unix time format might be an unsuitable time representation for
applications which require clock precision or time precision within a
few seconds for the purposes of Ti
There was a useful nanog presentation somewhere that explained this really well
in particular reading traceroutes correctly
Kind regards
James Greig
> On 7 Jul 2016, at 20:17, Phillip Lynn wrote:
>
> Hi all,
>
> I am writing because I do not understand what is happening. I ran mtr
> agai
James,
You may be thinking of this presentation:
https://www.nanog.org/meetings/nanog47/presentations/Sunday/RAS_Traceroute_N47_Sun.pdf
-mel beckman
> On Jul 10, 2016, at 4:49 PM, James Greig wrote:
>
> There was a useful nanog presentation somewhere that explained this really
> well in pa
In message <25577fe1-6366-4d6d-b82e-a779193cb...@beckman.org>, Mel Beckman writ
es:
> Philip,
>
> Quite often slow Web page loading and email transport -- termed an
> application-layer problem because basic transport seems unaffected -- is
> due to DNS problems, particularly reverse DNS for the IP
9 matches
Mail list logo
