[190578] in North American Network Operators' Group
Re: Leap Second planned for 2016
daemon@ATHENA.MIT.EDU (Patrick W. Gilmore)
Fri Jul 8 21:39:22 2016
X-Original-To: nanog@nanog.org
From: "Patrick W. Gilmore" <patrick@ianai.net>
In-Reply-To: <CAAeewD_kxj2g4=XaNk8jj5DCp8hEhtNY5JhAQesCyYGVy8Opew@mail.gmail.com>
Date: Fri, 8 Jul 2016 21:39:32 -0400
To: NANOG list <nanog@nanog.org>
Errors-To: nanog-bounces@nanog.org
On Jul 8, 2016, at 7:47 PM, Saku Ytti <saku@ytti.fi> wrote:
> On 9 July 2016 at 02:27, Jared Mauch <jared@puck.nether.net> wrote:
>> Time is actually harder than it seems. Many bits of software break in =
unexpected ways. Expect the unexpected.
>=20
> Aye. How many have written code like this:
>=20
> start =3D time();
> do_something();
> elapsed =3D time() - start;
>=20
> Virtually all code dealing with passage of time assumes time moves
> only forward, I'm amazed we don't see more issues during leap seconds.
> Portable monotonic time isn't even available in many languages
> standard libraries.
>=20
> Hopefully they'll decide in 2023 finally to get rid of leap seconds
> from UTC. Then GPS_TIME, TAI and UTC are all same with different
> static offset.
But time _DOES_ flow. The seconds count
58, 59, 60, 00, 01, =E2=80=A6
If you can=E2=80=99t keep up, that=E2=80=99s not UTC=E2=80=99s fault.
As for stopping the leap seconds, talk to the planet Earth. It=E2=80=99s =
the one who will not conveniently rotate properly. Either that, or run =
REEEEEEALLY Fast in that -> direction every once in a while. :-)
--=20
TTFN,
patrick
