F-ckin Leap Seconds, how do they work?

Wed Jul 4 04:19:49 UTC 2012

On Tue, Jul 03, 2012 at 04:53:32PM -0700, Owen DeLong wrote:
> 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.

	Owen, 

	...that is going backwards, since we'll repeat 59.XXXXXX.

	Which is really bad for a lot of applications, system timers,
pretty much any database, sleep mechanisms, locking mechanisms, etc.

	What happens if you were trying to execute some code at 
59.5926725?  Has it already happened or is it yet to come?
Looking back at two financial transactions, which came first?

	I've had an environment where large reverse steps occured with
some regularity -- you don't want to go there.  At all.  There is a LOT
more software that wigs out when you reverse step the clock (which you
will be, if you 'repeat' a second.) than does when a leap occurs.

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

	You must have written some NMEA code in a past life.

	I'd be fine with rolling TAI for systems use, but it does
not make much sense to condemn the leap second in UTC for this.
We've had a fair number of them, in the Internet age, without this
much trouble.

	This is about bad software development.

	If you change something like the leap second handler in your
code, please test it.  If not right away, before 2 more leap seconds
have occured several years down the road.  

	Also, people that build production environments on operating
systems that do not receive that sort of testing, do so at their own
risk.  That's their fault, despite any fist shaking/angry tweeting 
at 23:59:60.

	It's pathetic that advertising clocks in public places can get
this right (and did in 2008) and 'the Internet' cannot:

	http://www.youtube.com/watch?v=PJ4TWChcKpI

	--msa