Leap Second To Be Added Dec 31, 2008 255
ammorris writes "Don't be the laughingstock of your friends when you shout 'Happy New Years' a second too early ... The International Earth Rotation and Reference Systems Service has announced that a leap second will be added on December 31, 2008 at 23h 59m 60s, meaning that this year will be exactly one second longer. The last leap second occurred Dec 31, 2005; they are added due to fluctuations in the rotational speed of the earth. You can read all about leap seconds on Wikipedia."
Re:Gee, thanks for the notice (Score:5, Interesting)
Uhh, wouldn't it be nice if we were given a little bit more of a warning? Say, something like, oh a week?
You may laugh, but I work in Air Traffic Control. We rely on absolutely precise timing in a system distributed over 1000s of kilometres. Many components can be marked as non-functional by the system if they appear to have an incorrect clock.
Every time we add a leap second we get issues raised. I have to say it is a real PITA.
While we're at nitpicking (Score:3, Interesting)
What timezone will it be added to at midnight?
Yes, I know, it is not nitpicking because it's nontrivial for certain high precision science projects... even though I couldn't think of one right now, but it's gonna be quite important for someone.
But just to add a joke: Effin' great, as if daylight saving didn't put enough stress on the mechanics of my clocks!
Re:how will my computer know (Score:4, Interesting)
I don't suppose this leap second has been encoded into timezone information like daylight saving time has been.
So I would just run ntpd and expect the clock to step 1 second.
At second thought, I would expect ntpd to gradually slew system time since 1s is too small an offset to step the clock at once. Maybe it would be better to stop ntpd and restart it with -g or even delete its drift file since this second is not an error of the system clock but artificially introduced? Anyone know?
Re:Gee, thanks for the notice (Score:5, Interesting)
Yeah, we had problems in Google with these too; we have large networks of machines that used to use multiple different NTP servers (for resilience). Turns out not all NTP servers implemented leap seconds the same way, and many cluster based applications get upset when they aren't synchronized to within 100ms.
Now, we run a dry-run of a fake leap-second with all software a few weeks before the leap-second failover. It's the only way to be 100% sure that applications changed since the last leap second won't have problems. Though, most unittest frameworks now have the ability to implement second skewing, since the suffering caused by the 2005 leap second.
The main problem is that the POSIX description of how to do a leap second is retarded; you basically go from 00:00:00 to 00:00:59, some apps also get upset when they see the same time twice.
John
Fluctuations? (Score:3, Interesting)
Re:Gee, thanks for the notice (Score:5, Interesting)
Some people mistakenly think NTP is a silver bullet for handling timing issues.
NTP is great for keeping consistent time *over time*. It is horrible for handling stuff like a leap second, it simply takes too long.
Some systems use GPS, some use IRIG-B and some use NTP. Some handle leap seconds and some don't.
If you work with telemetry, like I do, you need time to be 100% correct all the time or else the data is worthless. This leap second is actually causing NASa and other space agencies to not do satellite supports close to midnight on new-years eve UTC.
Re:Gee, thanks for the notice (Score:5, Interesting)
Re:Gee, thanks for the notice (Score:3, Interesting)
Re:how will my computer know (Score:3, Interesting)
NTP does include leap seconds if your timeserver knows about it, which all good timeservers should do. It shouldn't show up as a slew if ntpd behaves properly, it's a distinct step. Have a look at your logs after midnight and see if it's there.