This is definitely something you should worry about if you rolled any of your own time code. The POSIX standard is consistent across days, including leap seconds. That means that your Unix timestamp will jump back a second: it will go from 1341100800.9...[0] to 1341100800. If you're relying somewhere on seconds being continuous, or on a one-to-one mapping between timestamps and seconds, this could fuck things up.
Although 1341100800 refers to two seconds, when converting to UTC it should always become 00:00:00. Your implementation may not be conforming to the standard, though. Make sure to test.
(I'm sure if you rolled your own time code, you already know about this stuff. Probably other folks are curious though :)
[0] I think this is the second we're talking about, not positive though.
I've found or read about bugs in nearly every stdlib time library I've ever worked in, except Joda time[1].
If you rolled your own, you should worry more, but you should still think about it even if you didn't roll your own.
[1] Joda is awesome, and by far better than any other time lib out there, but even they have bugs they're fixing in JSR310 (http://jcp.org/en/jsr/detail?id=310)
Amusing, but the issue is not really gaining or losing seconds, but keeping the clock synched to the rotation of the Earth. As long as we're going to all the trouble of dealing with timezones to make sure our wall clocks have a roughly consistent relationship to when the sun is in the sky, we should be doing this kind of thing as well.
No we shouldn't. If everything was done perfectly, then on average your timezone is already out of whack with local solar time by about 15 minutes or so. Of course we don't do it perfectly, most of us jump another hour back and forth each year for no particularly good reason. Who cares about another second? Just let solar and calendar time drift apart.
The amount of time until a timezone is noticeably out of whack with solar time is substantially longer than how long timezones have existed in anything like the modern form. In a thousand years maybe we'll start moving timezones around. But the cost of moving them for astronomical reasons will happen orders of magnitude less often than moving them for random political reasons.
I have read arguments both ways. And I remain convinced that letting UTC slowly drift away from Greenwich is a perfectly reasonable solution that will save us from many potential software bugs, and will cause no significant disruptions in life for the next ten thousand years. Of course eventually the Earth's rotation will slow down enough that the drift of time zones will become noticeable on a human time scale. But that problem is many thousands of years off, let them solve it then. If all goes well they will have had to figure out how they want to handle local calendar time not fitting UTC for people living on asteroids and other planets, and can just adapt that solution to Earth...
But when you have that specialized need, it is easy enough to remember an offset. And less work for the handful of people who want that to look up the offset (which only changes every few years) than it is to expect every clock in every computer to change every so often.
The only people who really benefit from this are a handful of astronomers. But they are already used to keeping multiple clocks, and having them adjust their software programs is less work than having everyone else's computers reset.
Me too. I'd be really interested to hear their story. Has anyone been involved with fixing a system that would have been provably broken by stuff like this (and other things like Y2K)?
Bonus points if you were working on critical public infrastructure like a nuclear power plant.
At least on Cisco systems, you can add a leap second [1], and at least on my network the tolerance is set at 5 minutes. So network time should still be working. For clients that might not know how to deal with a leap second but still poll network time, I only see issues in the rare case that the client polls the server at exactly 23:59:60. In that situation, they might poll back again to grab a new time thinking it's wrong.
Of course there will always be outliers and poorly coded applications that rely on time, but at least it's not a Y2K style situation.
