Slashdot Mirror
Leap Second To Be Added Dec 31, 2008
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."
I tried to resist, but I still leapt at the chance...
Uhh, wouldn't it be nice if we were given a little bit more of a warning? Say, something like, oh a week?
Gah! I can't take another second of this!
"Kittens give Morbo gas!"
Until 2007 legal time in the US was mean solar time, and that has no leaps, so this is the first leap second for the legal US time. Officially, of course, USNO and NIST were keeping UTC, but that didn't make it legal. The difference shows up in computer time scales.
"Don't be the laughingstock of your friends when you shout 'Happy New Years' a second too early ... this year will be exactly one second longer."
So... wouldnt we be shouting it one second later than everyone else?
Yes, yes, that's Nix vs Hedden and it was ruling by the U.S. Supreme Court in 1893. The court ruled that in the common parlance of the time a tomato was seen to be a vegetable and not a "fruit of the vine", working from the assumption that most people at it for a main course instead of a dessert. I think that if you were going to pick up on the ridiculous nature of the case you'd focus on the reason behind the court case — that taxes needed to be paid on imported vegetables and yet not on imported fruit.
XML is like violence. If it doesn't solve the problem, use more.
Those of us in the U.S. will get to celebrate our extra second during a reasonable time of day, as it's in UTC. The local astronomy museum generally has a baloon drop at that time, so that the kids can feel they celebrated New Year's properly.
Bruce Perens.
Only if you're reading this from 2007.
Disconnect and self-destruct, one bullet at a time.
If you messed up in 2008 you still have an extra second to make good.
DON'T WASTE THIS GOLDEN OPPORTUNITY!
I work a graveyard shift. You can bet I'll bring this up to the boss. I don't work for free!
If you want news from today, you have to come back tomorrow.
Wait just a second, now! I ... oh.
A truly excellent pizza parlor is a delight unto the heavens. Treasure the sauce and the toppings!
Bush will do anything to remain president just a little longer.
I will be able to give my GF an extra round of pleasure, with time to spare.
/.'er and obviously don't have a GF. But if I did, I am confident in my abilities that I could, in fact, perform my duties in the allotted one second.
OK, just kidding - I am a
Slashdot "libertarians": Small government for me, big government for those I disagree with. -1, I disagree with you
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!
We used to have a Bill of Rights. Now, with the rights gone, all we have left is the bill.
The International Earth Rotation and Reference Systems Service has announced that a leap second will be added on December 31, 2008 [CC] at 23h 59m 60s
My understanding is that the last 60 seconds of the year will be 1/60th of a second longer. Or will my GPS actually read "23h 59m 59s" twice?
I'd rather you do it wrong, than for me to have to do it at all.
It seems wikipedia is experiencing that second right now... over and over again in a persistent loop of doom!
Err, no, it's just been slashdotted!
-Kinsey
Or, is that only in the vista ultimate edition?
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?
Of course it runs NetBSD. BTC: 1NT7QvbetmANwaMzhpVL6
This is just plain stupid. If in 30 years sun rises like, 10 seconds too late, oh my, we'll just have to adjust. Geez.
No big d.......eal.
Table-ized A.I.
Second?
I'm sorry? Fluctuations in the rotation of the earth? You mean the earth is accelerating and breaking? It has nothing to do with the fact that a rotation around the sun is not exactly 365.25 rotations around our own axis? hmm...
The UTC second 60 gets added at midnight only at those locations where UTC == local time, i.e. places like England.
For us in the rest of Europe, the leap second will be added an hour after local midnight, i.e. at 01:00:60 CET.
Terje
"almost all programming can be viewed as an exercise in caching"
"No matter how hard we rant and scream about what a mess our predecessors made with their concept of reality, we can't get them to fix what they did. We just have to cope and move on. The best we can do is not to make the mess worse for our posterity."
from the link posted above. Interesting read. I still wonder why we have a leap year, no need of it. I never got over what I learned from a bunch of unix chat servers world wide linked together. Absolutely amazingly Wrong, when time and reality have to work in milliseconds or seconds around the world together. leap year is dumber than a carpocalypse..oh wait.
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.
What I find baffling is that architects/developers working in such a life-critical field managed to conceive application relying on days/minutes which are NOT fixed values. (a minute can have 59 or 61 seconds while a day can have 23 or 25 hours).
That said, the clock of a Un*x system is usually calibrated in milliseconds since the epoch and this has absolutely zero, nada, zilch, nothing to do with leaps seconds. The fact that we decide that 31 dec 2008 with have a 61 seconds minute change *nothing* to the correct calibration of the clock.
How distributed systems across the globe came to rely on hh/mm/ss speaks, well, a lot about the plain dumbness of many people.
But do they really? I pity the poor sick, under-brained people who designed those GPS if they're really that deeply flawed.
Leap years are a separate issue. They keep the calendar in sync with the seasons. Leap seconds keep our clocks in sync with the apparent positions of the Sun and stars.
Mea navis aericumbens anguillis abundat
Leisure-suit up! This is going to be legend... wait for it...
-- My Sig is a P228.
Is that true?
I know that this is how timezones, DST and leap years are handled, but are leap seconds handled like this too?
In other words, if I ask a Un*x system about the number of seconds since epoch for 2008-12-31 23:59:58 UTC and 2009-01-01 0:00:01 UTC will there be a difference of three or four seconds?
Well, it is easy to test, so why do I ask?
$ date --utc --date "2008-12-31 23:59:58" +%s
1230767998
$ date --utc --date "2009-01-01 00:00:01" +%s
1230768001
Difference is three seconds, not four. It seems you are wrong, or my Debian Stable has an incorrect implementation of unix time.
....the faster time flies by...
But damn'it... ya all don't have to help it.
Sorry, but that is exactly the point. Unix time was given as an example of a correct time implemention using a fixed base, but as far as I can see, it does not use a fixed base in this particular case. If it did, ntp deamons on unix systems would not have to slew or jump the kernel clock when a leap second is inserted.
Leap days and leap seconds serve different purposes.
Leap days are because our definition of a day (and thus a year) are not exact. A year is actually ~365.25 days, so we add an extra day every 4 years to compensate.
Leap seconds are needed as there's another small random variance in the length of a day (The mean solar day lengthens by about 1.7ms per century, due to slowing of the earth's rotation), so we occasionally need to add a second to keep us in sync with astronomical time.
upon the advice of my lawyer, i have no sig at this time
To be subtle, they added the leap second to the one time in the entire year when everyone (at least in that time zone) is watching the clock and counting along with it.
Defer leap seconds for a few years.
And have "leap days" instead.
Always to be on a Monday or a Friday (no weekend leap-days allowed).
I get the new second in 2009 since I live in UTC +1
leap-second
Summary: NTP and GPS know about leap seconds, operating system might not.
From TA:
"Linux kernels and most other Unix-like systems care about the leap seconds and handle them correctly. Some systems even add a notification to the system log when the leap second is inserted."
"The Windows system clock does not know about leap seconds, either. However, there is a precompiled version of ntpd for Windows available which is capable of slewing the Windows system time quickly in order to account for the insertion of a leap second, without affecting the clock synchronization loop provided by ntpd."
Which leaves two problems to be solved in a practical implementation:
1. You have to use GPS receivers which actually shows true GPS time, not GPS time corrected to UTC.
As someone has stated in another part of the discussion, GPS receivers will receive GPS time from the satellites, but they also receive a UTC correction which is calculated into the time which is reported by the device.
2. You have to chose how you will handle this in your network, across different platforms:
2a: Let your time daemons run GPS time internally (using your own GPS-based NTP servers for synchronization). This means that you will have to implement time correction in all software which needs to know/display correct UTC time.
2b: Let your time daemons run GPS time internally but report UTC time to any software which asks. This means that you probably will have to develop your own time daemon for all platforms in use in your network, unless solutions already exists.
My point is that it is too easy to just say "What I find baffling is that architects/developers working in such a life-critical field managed to conceive application relying on days/minutes which are NOT fixed values."
When the recognized de facto industry standard of timekeeping doesn't have an optimal solution for leap seconds, there is a very hard choice between doing things right and risk adding your own errors in your home-made solution or doing things less right and at least use a proved solution.
Ten!
Nine!
Eight!
Seven!
Six!
Five!
Four!
Three!
Two!
One!
One!
Happy New Year!
That means that the valid range for seconds is 0..60 and it is possible to have 61 seconds in a minute. You need to know this if you are using a programming language with range checks.
Oh, shit.
Well, at least I'll know what I'll be doing on my first day of work next year.
Schroedinger's Brexit: The UK is both in and out of the EU at the same time!
I do like how people complain that they are trying to keep 'time' in keeping with actual observed sun/earth movements. If anyone is seriously using HH/mm/ss as an accurate system should move out of the pre-war era into the new fangled world of the microprocessor. I don't know about anyone else but I have in the past tried to do things with a computer and HHmmss and bugger me that was hard, then I used unix timestamps and lo life was easy (as long as someone has already done the module to convert timestamps to HHmmss to make the time readable again, although this should only be for output not further processing). But you could always use something like http://en.wikipedia.org/wiki/International_Atomic_Time if you really need to have an accurate time source. UTC should keep time in sync with the sun, if not midnight would become noon in a 'few' years, which would just be plain silly.
Damn. I've been following the International Earth Rotation and Reference Systems Service (IERS) emails for years and this one managed to slip into my spam filter. Thanks slashdot! for making sure I didn't miss it this year!!!
(A great bonding moment with my father was counting along to 61 with the atomic clock signal on the short wave while sitting by the sundial at the local science museum...)
This sig intentionally left justified.
Wow, that's such a crappy definition. It clearly states a linear time scale, while it is not actually linear.
Tsunami -- You can't bring a good wave down!
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.
How many people can read hex if only you and dead people can read hex?
No it isn't. It's a 86401 seconds longer. Than last year. Or 86400 longer than the previous leap-second-year 2005. Oh, yeah, it's exactly 1 second longer than 2004 and 1996.
I confess enjoying myself as a time nazi. Should not forget to count february 29th...
The stock market will lose 20% of its value and the government will give an extra bagillion dollars in bailout money.
/sarcasm
Let's be done with '08 already - let's add that extra second to a good year
If you can read this... 01110101 01110010 00100000 01100001 00100000 01100111 01100101 01100101 01101011
Leap seconds get added all the time. They can't be predicted years in advance. http://en.wikipedia.org/wiki/Leap_second
If you are running NTP or have a radio-controlled lock they will handle this just fine.
If you have a real atomic clock you don't care, atomic clocks never get reset.
Otherwise, you have a couple days to fix your bugs.
Give a man a fish and you have fed him for today. Teach a man to fish, and he'll say "WHERE'S MY FISH, YOU IDIOT?"
Astronomers have been measuring subtle changes in Length-of-Day for decades. Its the advent of atomic clocks that has made this very precise. Length-of-Day responds to changes in mass distribution in the earth - like the spinning ice-skater who extends or contracts arms to change spin rate. Generally the main cause are ocean currents and seasonal weather patterns. In turn, these may be affected by small changes in solar output. Very large earthquakes like Indonesia 2004 will lift or drop enough rock to affect the the rotation rate. Glacial melting, increased/decreased erosion may change it too.
There's also a theorized seasonal component caused by sap rising and leaves growing in trees in alternate hemispheres, but that's pretty well down in the noise.
rj
I think it would be advisable not to rely on any system implementation of time, but to go with a completely separate time system. It can't be any more borken than the stuff you buy.
Ah, the naivete of youth.
I guarantee your implementation will be more "borken" than the stuff you buy. Accurate timekeeping is complex, even if you ignore conversion to wall clock time, and accurate time synchronization is even harder.
A wise engineer will use the thoroughly-debugged implementations available, and implement a simple correction factor to address the leap second offsets that are not handled smoothly by the off-the-shelf code.
Note to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.
5... 4... 3... 2... 1... 1...
Happy New Year!
April Fool!
Of course, this is a carry-over from the Roman new year.
Were that I say, pancakes?
Check it again after ntp sends the change signal to your system (do you even have NTP on?).
I don't expect anything different, but the experiment is somewhat useless at the moment.
Liberte, Egalite, Fraternite (TM)
There is no simple correction factor which solves all use-cases. The "right" one depends on what you need the time value for: Duration? Point in time?
Sure there is. In fact, you described it in your post.
Use UTC-corrected timekeeping infrastructure, and keep a list of leap seconds so that you can "de-correct" to remove leap seconds. Store and calculate with de-corrected times. When you need to display human-readable times, first re-apply UTC correction and then use the standard conversion utilities. Handles all cases, and is MUCH simpler than replacing your system's timekeeping infrastructure.
Note to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.
If you are distributing UTC inside and outside your application, then you have created a huge error.
Bah.
You have an "error" that is (a) irrelevant to most applications and systems and (b) can be relatively easily worked around for those applications that need non UTC-corrected time. In fact, the UTC de-correction needed by those applications requires the same infrastructure as that which would be required by all systems if they used TAI or GPS time internally and applied correction to display UTC time for human consumption. The only difference is that if systems used TAI internally, they would ALL have to be updated every time a leap second was announced. As it is, only applications that actually care about the issue have to be updated.
Note to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.
3 2 1 jokes in 3... 2... 1... 1...
Gravity is a contributing factor in nearly 73 percent of all accidents involving falling objects. -Dave Barry
Um, no, that is not true. Unix time is kept in non-leap seconds elapsed since a defined point in time. Look it up.
Are you adequate?
If we leap one day in a "leap year" then shouldn't leaping a second be called a "leap minute" and not a "leap second"?
Cow Cube
Drop leap seconds from the time stream and put them in the timezones file. Universal time should be an uninterrupted stream of numbered "atomic" seconds: TAI. Thus rather than the silly dance we are about to go through the IERS would simply publish a notice stating the number of seconds to be added to TAI to convert to UTC after the effective date.
Computers would keep time, record timestamps, etc in TAI as the do now in UTC and would apply the appropriate leapsecond adjustment when they formatted time for display along with time zone and DST adjustments. The timezones file would contain enough information to permit times in the past to be correctly displayed.
Warning: this article may contain humor, sarcasm, parody, and perhaps even irony. Read at your own risk.
Can't give you any figures, but one second off would mean a lot of lost cash for us here at WeTalkToSatellites.
Not enough to put us out of business, but enough to cause the execs to come screaming with tears.
During the leap second, is it considered 2008 and 1/2?
"Vegetable" is a culinary term, not a scientific one. Fruits can be vegetables.
-- http://ninthagenda.com/
Well, the big problem is that the lengthening of the mean solar day is not a constant rate. You can't predict when leap seconds will be needed in the future with any accuracy.
Wolde you bothe eate your cake, and have your cake?