[154429] in North American Network Operators' Group

home help back first fref pref prev next nref lref last post

Re: F-ckin Leap Seconds, how do they work?

daemon@ATHENA.MIT.EDU (Owen DeLong)
Tue Jul 3 19:58:16 2012

From: Owen DeLong <owen@delong.com>
In-Reply-To: <20120703200953.GA16042@pob.ytti.fi>
Date: Tue, 3 Jul 2012 16:53:32 -0700
To: Saku Ytti <saku@ytti.fi>
Cc: nanog@nanog.org
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org


On Jul 3, 2012, at 1:09 PM, Saku Ytti wrote:

> On (2012-07-03 12:46 -0700), Owen DeLong wrote:
>=20
>> If you don't know that time is not monotonically increasing, then =
that only becomes a software bug when you codify your own ignorance into =
software you write.
>=20
> If only all software could be ordered from you Owen, but in practice =
this
> is not possible. Some code will be written less intelligent people. =
And
> reviewing any code doing foo =3D timestamp+offset and if now > foo, =
virtually
> never expects time to move backwards.

Sure, but even with that, 99% of it has only a passing 'interesting' =
effect and
then recovers.


> UTC doesn't move backwards (it goes 59 -> 60 -> 00). TAI does not move
> backwards. Unixtime moves backwards, like spanish inquisition no one
> expects that.

UTC (and the system clock) should not move backwards, but, rather they =
repeat
second 59. UTC goes 58->59->00 most of the time, but during a leap =
second, it
should go 58->59->59->00). It's not so much going backwards as dropping =
a chime.

>> It is well known that leap seconds exist.
>=20
> Quite. But it is not well known that unixtime travels backwards.
>=20

In part because it shouldn't actually do so. It should simply chime 59 =
twice.

Owen



home help back first fref pref prev next nref lref last post