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.
HOw will my computer know to add on the extra second? I run the CentOS
"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?
well, the USA has also legally declared the tomatoe to be a vegtable, even though it's not (it's actually a berry..). i guess it's what happens when a nation has to low brow everything.
If you mod me down, I will become more powerful than you can imagine....
If you don't mod this down you are not a patriot.
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.
The Year 2008 + 1sec Bug?
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.
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?
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. The adjustment will only be available in Windows 7, under 3 metric tons of hidden registry keys and with an unwritten "WARNING, THIS COULD CRASH YOUR SYSTEM!!!" sign.
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.
Scientific clocks need to get off Earth time and just have a clock counting seconds from a certain point in time.
AC gets all the points, thread closed.
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.
That's beside the point. If you need to synchronize different systems or measure exact durations, don't use a timescale which fluctuates with the unpredictable rotation of the Earth. Of course the algorithm used by the date program can't know that there is an extra second between 2008-12-31 23:59:58 UTC and 2009-01-01 00:00:01 UTC. That's empirical information encoded in a rather arbitrary decision to add a second right there (or worse, remove a second at some other time).
Unix time is kept in the only unit that doesn't change: seconds elapsed since a defined point in time (milliseconds actually, but the base unit is the second). The other units of time (minutes, hours, days, months, years) are all variable length units, not suitable for keeping accurate and precise time. The conversion between a date/time in these units and milliseconds since the Epoch is mostly algorithmic, but involves those pesky leap seconds, which can not be taken into account for future times and must be recorded in tables for past times. Ask yourself if you really want or need to do this conversion to synchronize different systems. For purposes of synchronization, points in time should simply be specified in seconds (or fractions thereof) since a defined point in time.
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.
Why not let all systems freak out for the minute it takes for the timing to correct it's self.
it's not like any company will have $100,000,000 in sales during the 00:00:00-00:01:00 Jan 1 2009 time period. Even the loosely designed NTP will slew in that 1 second within a minute or so.
Finally, what is the big deal about haing your equipment 1 second off for a while.
"WE would nail those thieves, but your logs are off by 1 second, we cant prosecute them!"
Time is relative, and if your system time matches across your system, then that is all that really matters. The FAA will not freak out if the plane landing logs are off by 1 second, anything critical can stay 1 second off until a service down time window can occur to reset the time clocks.
Do not look at laser with remaining good eye.
OK, had to read up on it. You're correct, the Unix guys screwed up too. The definition of Unix time is seconds since 1970-01-01T00:00:00Z, not counting leap seconds. They could have left that last bit out and gotten a really useful time facility, but they had to ruin it, presumably to simplify the date/time conversion.
So, the right way to synchronize systems is not to use Unix time but the number of seconds (or fractions thereof) since a defined point in time. Use GPS time.
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!
Yes, it is a mess. I've just read up on the definitions of the Java Calendar class and can't stop wondering what these people were thinking. The API doc starts with a preface detailing most of the problems affecting timekeeping: time zones, leap seconds, etc. Then the method documentation stresses that seconds can be 0-61 due to leap seconds. And then Sun's implementation completely ignores these issues and just does the Unix time calculations and equates that to both UTC and GMT. It would be acceptable to rely on an improper system time for "now()" if no better time source is available, but the Calendar class doesn't even try to do the calculations correctly.
In that light, 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. Internal timekeeping should simply count seconds (seriously, is that so hard? If the counter is at x now, then it is at x+1 one second later.) Everything else can be derived from that with algorithms and tables of leap seconds.
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.
I, for one, will celebrate NYE both times it passes me by. Woo-hoo woohoo.
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!
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...
It seems ironic that an article about timekeeping should be several months late...
I recorded the last leap second off WWV. I plan to record this one too. WWV omit the 29th and 59th second ticks, so the leap second sounded something like this:
tick (23:59:57)
tick (23:59:58)
(silent) (23:59:59)
(silent) (23:59:60)
beep! (00:00:00)
tick (00:00:01)
tick (00:00:02)
...laura
year : A unit of time it takes for the Earth to complete one orbit around the Sun
years : an ambiguous length of time consisting of at least one year (1.5 years, 200 years, many years)
year's : possessive of a year (That year's highest temperature)
It's "New Year's Eve", as is the eve of the new year. Meaning the day before the calendar year changes a
It's not "New Years" (this makes no sense) or "New years eve" (again this makes no sense)
It is "The new year" or "Happy new year" or "Happy new year's day" though even that last one seems a little odd. It is the actual changing of the year you are celebrating.
On another note, why are there never any celebrations of the new months? Happy new month, New month's eve, etc? Seems bars would make more money pumping up these holidays like Hallmark has with all the other made-up ones.
>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.
HA HA HA!
The "optimal solution" has been shown to be fragile to the point of putting human life in peril. "Yes, sir, we must synchronize the motion of the airplanes to the rotation of the planet. Can you not see the connection?"
All of this because some human nitwit wanted to be able to ask an ATC computer about the wall-clock time was.
All the object oriented programming, agile development, and keen systems engineering are for naught if you begin from totally stupid requirements and premises.
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.
This sounds like a kludgy fix. Why not address the real problem, i.e. the unstable rotational speed of the world?
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.
I am no time scientist, but it is likely because linear number systems are not perpetual. A very fine time resolution like nanoseconds would rack up a very large number very quickly. Designing a system that will not overflow when the number gets too high would be a problem. GPS needs to run on small devices with limited resources. Devices designed to use the traditional date/time model will not need to add an extra digit for almost 8000 years.
5... 4... 3... 2... 1... 1...
Happy New Year!
implement a simple correction factor
That is called "job security": Making a complicated mess even more complicated by adding another small parameter which needs to be tuned just right. 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? Different assumptions about the requirements lead to different "corrections", which lead to systems falling out of sync.
I didn't mean you should start from scratch. You take what you know to be a time source of sufficient quality (GPS would be a candidate, or even NTP-corrected Unix time on any other day) and base a counter on that source in a way that it always progresses 1 second per second (I wonder if I'm the only one who is disturbed by having to specify that a time-keeping facility should count one second per second). That's easy for GPS if your receiver gives you GPS time, and a little harder for UTC: you'll need a table of leap seconds which can be updated to account for future leap seconds. Basically convert a (for synchronization purposes) bad representation of time into a good one by algorithmically removing all irregularities, then make your systems use that time exclusively. Bonus points if you can standardize on an existing sane linear timescale.
April Fool!
Of course, this is a carry-over from the Roman new year.
Were that I say, pancakes?
>I guarantee your implementation will be more "borken" than the stuff you buy.
If you are distributing UTC inside and outside your application, then you have created a huge error.
This is completely independent of the "system implementation of time", even ones that you may "guarantee", by whatever process -- even purchasing! -- to be completely bug-free.
This issue transcends the "implementation": this is systems engineering. Sad to say it, but yours is _BUSTED_ by design.
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
Remember to start the countdown with an extra second.
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.
The problem with that approach is that the system time does not differentiate between 23:59 and 23:60. It's both 23:59 as far as Unix time is concerned (either standing still or repeated twice). To have a time facility which counts linearly, you have to use your own timers, synced with corrections at times when you know that the system time isn't playing tricks on you. Of course, if you have a reliable UTC source, you can use that and just convert it, but Unix system time is fundamentally broken, and so is the Java implementation that I tested, even though the documentation is written as though it should handle UTC correctly.
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.
Make that 23:59:59 and 23:59:60.
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/
You are making no sense at all.
Two scenarios.
1) The system in question doesn't care about leap seconds. This is handled by simply pretending TAI is UTC: just change the display strings and your job is done. This can be done via simple configuration, needed for many other purposes. (cf. "locale").
2) The system must accommodate leap seconds. If so, then carrying around leap-second info inside the system (in and out of process) is, frankly, an error prone stupidity that must be avoided. The only rational approach is to gather and display UTC data only at the terminals of your system, and no where else, and deal with TAI (or an analog of it) everywhere else.
Carefully note that in both cases, TAI is used internally and UTC, if needed, are present only at the extremities. Also note that if one day the first system is given a new "we need to handle leap seconds" requirement, simply update the aforementioned configuration file(s) and test your terminals.
That you perceive the latter as "complex", and dealing with UTC pervasively throughout the system as (somehow) simpler, is indicative of a lack of systems experience.
Naivete of youth, you say?
The Precision Time Protocol (PTP) is a time-transfer protocol defined in the IEEE 1588-2002 standard that allows precise synchronization of networks (e.g., Ethernet). Accuracy within the nanosecond range can be achieved with this protocol when using hardware generated timestamps. http://en.wikipedia.org/wiki/Precision_Time_Protocol
Close enough?
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?