[154398] in North American Network Operators' Group
Re: F-ckin Leap Seconds, how do they work?
daemon@ATHENA.MIT.EDU (Jay Ashworth)
Tue Jul 3 15:35:02 2012
Date: Tue, 3 Jul 2012 15:33:42 -0400 (EDT)
From: Jay Ashworth <jra@baylink.com>
To: NANOG <nanog@nanog.org>
In-Reply-To: <217021.1341327089@turing-police.cc.vt.edu>
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
----- Original Message -----
> From: "valdis kletnieks" <valdis.kletnieks@vt.edu>
> When the published API has been "the system clock is in UTC" for some 3
> decades, I hardly think it's acceptable to call apps "buggy" for assuming that
> the system clock is in fact using UTC and breaking if you switch it to
> something that's not UTC. And the new time *has* to have different semantics
> than UTC, because if it doesn't then what's the point of changing it?
Correct. It's very likely that there is *no* sufficiently compelling
application requirement that justifies switching NTP from UTC to UT1/TAI.
So far as I can tell, the *only* requirement is "I need to be able to
calculate unixtime<->ISO8601 reliably to the second for times further away
than the next possible leapsecond"; I have not had pointed out to me yet an
application which actually requires that; I'm 99 44/100% certain that there
isn't one with a sufficiently compelling story to break 3 decades of code.
Cheers,
-- jra
--
Jay R. Ashworth Baylink jra@baylink.com
Designer The Things I Think RFC 2100
Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII
St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274
