The IERS will be adding a second to time again on my birthday;
2015-06-30T23:59:59
2015-06-30T23:59:60
2015-07-01T00:00:00
Have fun, everyone. 
Cheers,
-- jra
So you need to wait one more second before you may pop the bottle?
Hey,
The IERS will be adding a second to time again on my birthday;
2015-06-30T23:59:60
Hopefully this is last leap second we'll ever see. Non-monotonic time is an
abomination and very very few programs measuring passage of time are correct.
Even those which are, usually are not portable, most languages do not even
offer monotonic time in standard libraries.
Canada, China, England and Germany, shame on you for opposing leapsecondless
UTC.
Next year hopefully GPSTIME. TAI and UTC are the same thing, with different
static offset.
The IERS will be adding a second to time again on my birthday;
This time around there are a number of Vendor C devices that will fail
in spectacular ways if not upgraded with a pretty new release -- Nexus
and ASR1K being the two most "interesting" among those I've reviewed.
The universal workaround is to simply disable NTP on your devices sometime on Leap-Second eave. This will let the clocks free-run over the one-second push, an event of which they will be blissfully ignorant. When you re-enable NTP after The Leap, normal, non-destructive, NTP convergence will occur.
Better, if you have a master NTP site clock, you need only disable it’s upstream NTP feed to isolate all the subsidiary devices. If you don’t have such a master clock, this is an excellent time to set one up one. I have found the Time Machines TM1000A GPS time server very inexpensive and super reliable:
http://www.newegg.com/Product/Product.aspx?Item=0N6-001Y-00007
-mel
The universal workaround is to simply disable NTP on your devices sometime
on Leap-Second eave. This will let the clocks free-run over the one-second
push, an event of which they will be blissfully ignorant. When you re-enable
NTP after The Leap, normal, non-destructive, NTP convergence will occur.
<randy>I encourage all my competitors to use this
approach.</randy>
If you're more than 128 ms off when NTP is flipped back on, it
will still probably step the clock, then start slewing it. So you've
skipped the leap per se, but your clocks will still jump forward quite
a bit.
This might isolate you from any leap second related failures,
but it does not protect you against the system clock being stepped.
If the leap pending information data persists, you might not even be
isolated from any leap second failures. You could manage to upset
the system clock even more.
Are your time servers correctly armed for the leap?
Better, if you have a master NTP site clock, you need only disable it’s
upstream NTP feed to isolate all the subsidiary devices. If you don’t
have such a master clock, this is an excellent time to set one up one.
I have found the Time Machines TM1000A GPS time server very inexpensive
and super reliable:http://www.newegg.com/Product/Product.aspx?Item=0N6-001Y-00007
$20 says that doesn't leap correctly. A lot of the inexpensive
units appear to be using NMEA speaking GPS modules, and there's no real way
to get leap information out of them. Many of them may ignore the
timestamps and just use the PPS, in which case they may persist a second
behind the world for quite some time.
--msa
Saku Ytti writes:
Hopefully this is last leap second we'll ever see. Non-monotonic time
is an abomination and very very few programs measuring passage of time
are correct. Even those which are, usually are not portable, most
languages do not even offer monotonic time in standard libraries.
Canada, China, England and Germany, shame on you for opposing
leapsecondless UTC.
It's a problem with POSIX, not UTC.
UTC is monotonic.
Next year hopefully GPSTIME. TAI and UTC are the same thing, with different
static offset.
The General Timestamp API that Network Time Foundation is working on can
solve this problem. People use different timescales for different
reasons. The Agile folks like the "pigs and chickens" analogy: in a
bacon and egg breakfast, the chicken is invested while the pig is
committed.
It's lame for a chicken to dictate to a pig.
It's lame to change an existing Standard. Leave that one alone and
choose to follow a new/different Standard.
If you don't have a system that can properly handle leapseconds, there
are several solutions to this, including:
- implement DLM's leap second process in the kernel, described over 20
years ago
- use the posix-right timezone files
- help Network Time Foundation get the General Timestamp API implemented
and deployed, which will let folks use whatever timescale they want.
Bad idea.
When restarting ntpd your clocks will likely be off by a second, which
will cause a backward step, which will force the problem you claim to be
avoiding.
There are plenty of ways to solve this problem, and you just get to
choose what you want to risk/pay.
If you are afraid that your routers will crash due to the leapsecond, then
it would help to disable the thing that you think will crash them. Even if
the router crashes when you enable it later on. Because then you can have
one router crash at a time and have it happen in a service window where you
are ready for it. Instead of having all routers in your whole network crash
at exactly the same time.
Regards,
Baldur
Baldur Norddahl writes:
Harlan,
This is cisco's recommended workaround, the ultimate conclusion of an exhaustive study of all Cisco firmware and after detailed post mortem analysis of two previous Leap seconds:
https://tools.cisco.com/bugsearch/bug/CSCut33302
GSS Leap second update
CSCut33302
Description
Symptom:
There are periodic leap second events which can add or delete a second to global time.
When the leap second update occurs the GSS might hang and have to be reload or the kernel could crash and the GSS would reboot.
Conditions:
The leap second update will be propagated via Network Time Protocol (NTP) or via manually setting the clock.
Workaround:
Workaround, Turn off NTP prior to leap second and turn it back on afterward.
Further Problem Description:
None
Or, in the immortal words of The IT Crowd: "Turn it off and on again!"
If you run non-IOS server software of such fragility that it can't tolerate time slewing, just shut it down and power back up after The Leap.
That's what your competitors are doing
-mel beckman
Mel Beckman writes:
Harlan,
This is cisco's recommended workaround, the ultimate conclusion of an exhau=
stive study of all Cisco firmware and after detailed post mortem analysis o=
f two previous Leap seconds:
Fair enough. And I've been trying to get Cisco to work with us for very
many years. They have yet to show any interest. But they'd be paying
us for that. We have no leverage with them.
But folks who are paying Cisco for support? For the number of years
Cisco has been using NTP and for the number of product lines that use
it, they could certainly do better. I know they were current when I did
the port for the MDS switch line, years ago.
You're right. Hopefully POSIX will become monotonic next year, by removal of
leaps from UTC.
On Sat 2015-06-20T10:48:17 +0300, Saku Ytti hath writ:
You're right. Hopefully POSIX will become monotonic next year, by removal of
leaps from UTC.
Probably not. The ITU-R has outlined four methods for this issue, see
http://www.acma.gov.au/Industry/Spectrum/Spectrum-planning/International-planning-ITU-and-other-international-planning-bodies/wrc-15-agenda-item-114
where of method A1, A2, B, C1, C2, and D not all of them remove the
leap second from UTC.
In any case, previous draft proposals have all specified a 5 year
interval from deciding to change until the change happens, so we
should plan for 5 more years of leap seconds no matter what.
What; not posixly-correct?
Cheers,
-- jr ':-)' a
Hey,
> The IERS will be adding a second to time again on my birthday;
>
> 2015-06-30T23:59:60Hopefully this is last leap second we'll ever see. Non-monotonic time is
an
abomination and very very few programs measuring passage of time are
correct.
Even those which are, usually are not portable, most languages do not even
offer monotonic time in standard libraries.
Canada, China, England and Germany, shame on you for opposing
leapsecondless
UTC.
Next year hopefully GPSTIME. TAI and UTC are the same thing, with
different
static offset.
Unlikely but here's hoping. I mean letting computers figure out slower
earth rotation on the fly would seem more accurate than leap seconds
anyway. And then all of us who do earthly things and would like simpler
libraries could live in peace.
shawn wilson writes:
... I mean letting computers figure out slower earth rotation on the
fly would seem more accurate than leap seconds anyway. And then all of
us who do earthly things and would like simpler libraries could live
in peace.
Really? Have you looked in to those calculations, and I'm only talking
about the allegedly predictable parts of those calculations, not things
like the jetstream, the circumpolar currents, or earthquakes.
H
Ok, forget that point - AFAIK, the only things that matter wrt time is
agreement on interval/counter and epoch, and stability. Right now we only
have agreement on interval.
So while I'd prefer a consistent epoch and counter, I'll live with whatever
as we have access to board agreement and stability (like this doesn't hit
NANOG every time with "uh oh").
I wonder how many of us are old enough to remember what that environment
variable *used* to be called before political correctness became important.
There are so many layers in that observation that I'm lost.
Was posixly-correct a purposeful pun on politically correct, and I've
missed it all these decades?
Or was it named something else earlier than that, which wasn't itself
politically correct?
Cheers,
-- jra