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