Re: Leap Second planned for 2016

2016-07-10 Thread Saku Ytti
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?

Re: packet loss question

2016-07-10 Thread James Greig
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

Re: packet loss question

2016-07-10 Thread Mark Andrews
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

Re: packet loss question

2016-07-10 Thread Mel Beckman
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

Re: Leap Second planned for 2016

2016-07-10 Thread Jimmy Hess
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

Re: Leap Second planned for 2016

2016-07-10 Thread Steve Allen
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

Re: Leap Second planned for 2016

2016-07-10 Thread Mikael Abrahamsson
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

Re: Leap Second planned for 2016

2016-07-10 Thread Jay R. Ashworth
- 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

Falsehoods programmers believe about time, etc (was Re: Leap Second planned for 2016)

2016-07-10 Thread Jay R. Ashworth
- 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