×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Leap Second To Be Added Dec 31, 2008

timothy posted more than 5 years ago | from the pregnant-pause dept.

Earth 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."

cancel ×
This is a preview of your comment

No Comment Title Entered

Anonymous Coward 1 minute ago

No Comment Entered

255 comments

Second! (5, Funny)

tirerim (1108567) | more than 5 years ago | (#26255685)

I tried to resist, but I still leapt at the chance...

Re:Second! (-1, Offtopic)

Anonymous Coward | more than 5 years ago | (#26255769)

I don't follow fluctuations in the rotational speed of the earth, but here's my story:

I dropped a brown rope this morning the size of a small black child. At one point, I wasn't sure if I was taking a shit, or it the shit was taking me. And while I'm on that point, what's the deal with taking a shit? Shouldn't it be leaving a shit? I'm certainly not taking anything with me when I'm done.

But back on topic, fluctuations in the rotational speed of the earth suck ass

Re:Second! (1, Offtopic)

Bordgious (1378477) | more than 5 years ago | (#26255859)

Is there a way to possibly block this particular "Anonymous Coward's" IP from posting? This offensive comment has been posted on every article I've seen posted today...

Re:Second! (0, Insightful)

Anonymous Coward | more than 5 years ago | (#26255991)

Offensive?
Seriously, it's a bit of fun that you may or may not see, depending on when you post (i.e., has he been modded to hell already?).

Oh wait, you're browsing at -1 and complaining?

He also does have a very good point, in that you're actually leaving a shit and not taking a shit.

Re:Second! (-1, Offtopic)

Anonymous Coward | more than 5 years ago | (#26256059)

Yeah, if that's offensive, then I know a certain big, beautiful, all-American football hero type that you should meet.

Re:Second! (1, Insightful)

Anonymous Coward | more than 5 years ago | (#26256069)

If you find that offensive, what are you doing on the internet?

Re:Second! (1, Informative)

quenda (644621) | more than 5 years ago | (#26256261)

Why are you drawing attention to it? Just let the moderation system do its job. It only takes one mod to drop an AC into -1 oblivion.

Re:Second! (-1, Offtopic)

Bordgious (1378477) | more than 5 years ago | (#26256285)

This is true, but the offense has been repeated at least three or four times today, and it seems like there should be a way of banning repeat offenders (such as the way it is possible on Wikipedia).

Re:Second! (4, Insightful)

Anonymous Coward | more than 5 years ago | (#26256455)

It's like raising a puppy. The worst punishment possible is to pay no attention.

The Internet is full of idiots/trolls/criminals/mentally ill. Banning is not a solution. After banning they just start to hide and use a proxy.

Ignoring is the best way.

Re:Second! (-1, Offtopic)

Anonymous Coward | more than 5 years ago | (#26256395)

Jesus, are you serious?

Welcome to -1, GET BACK TO THE OVERWORLD NEWBIE.

Mod parent up! (-1, Troll)

Anonymous Coward | more than 5 years ago | (#26255881)

That's so very true.

For the layman, "rope theory" is an extension of string theory which describes how strings and branes behave at the macroscopic level. The famous "Brown Rope" problem raises insightful questions and the answers to them are most informative. To expand on the parent's point, dark ropes tend to be very messy. In an ideal situation the rope is dropped with little perturbance and viscosity which results in the rope-dropper exercising translational and rotational motion away from the point of the original rope-dropping.

Now, take for example an alternate scenario: One in which the perturbance and coefficient of viscosity of the rope are very high. In this case, the case which the parent describes, the rope exhibits a sort of "stickiness". When a "sticky" rope drops, the dropper does not "have" the rope, the rope "has" them because the viscosity of the rope effectively binds the "dropper" to the aforementioned point of rope-dropping.

The problem of the sticky rope is best solved through an iterative approach. Wipe, wipe, flush, repeat until the working density of the rope approximately equals zero. The desired level of precision is dependent on the number of iterations computed at a trade-off of time vs. precision, though with modern technology high precision tends to be most popular result.

Gee, thanks for the notice (3, Funny)

holophrastic (221104) | more than 5 years ago | (#26255689)

Uhh, wouldn't it be nice if we were given a little bit more of a warning? Say, something like, oh a week?

Re:Gee, thanks for the notice (3, Informative)

Anonymous Coward | more than 5 years ago | (#26255699)

Technically, the original announcement was in July. This is just a reminder.

Re:Gee, thanks for the notice (4, Informative)

KiloByte (825081) | more than 5 years ago | (#26255701)

The bulletin is dated 4 July 2008, it's just the Slashdot article that's late. Or even, just on time as a reminder.

Re:Gee, thanks for the notice (5, Insightful)

fastest fascist (1086001) | more than 5 years ago | (#26255781)

No-one ever R's the FA, so the date on the bulletin is completely irrelevant. If it's not in a slashdot summary, we don't know about it.

Re:Gee, thanks for the notice (5, Interesting)

MichaelSmith (789609) | more than 5 years ago | (#26255713)

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.

Re:Gee, thanks for the notice (5, Informative)

xous (1009057) | more than 5 years ago | (#26255905)

Haven't they heard of NTP? http://en.wikipedia.org/wiki/Network_Time_Protocol [wikipedia.org]

Re:Gee, thanks for the notice (5, Informative)

MichaelSmith (789609) | more than 5 years ago | (#26255951)

Yes, but we are talking about interfaces between a lot of different networks, each of which have their own GPS based time reference. An NTP daemon in each network talks to the GPS device, but there is no way to be sure that all the daemons will slew the time at the same rate.

Re:Gee, thanks for the notice (-1, Flamebait)

Anonymous Coward | more than 5 years ago | (#26256075)

So you guys gotta deal with beeps and land the birds yourselves instead of mindlessly parroting your machinery. The ATC field has always been overrated compared to the others who actually fix shit.

Re:Gee, thanks for the notice (5, Interesting)

Anonymous Coward | more than 5 years ago | (#26256187)

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 (4, Interesting)

Detritus (11846) | more than 5 years ago | (#26256197)

NTP isn't good enough for many systems. Where I work, millisecond level accuracy and resolution is the bare minimum. Some applications require microsecond level accuracy and resolution. That's why we have dedicated timing systems and timing distribution systems. NTP is used on systems, like general purpose PCs, that don't have a requirement for accurate time.

Re:Gee, thanks for the notice (1)

xous (1009057) | more than 5 years ago | (#26256241)

This is true but perhaps I'm not understanding the full importance of precise time keeping in respect to the air traffic control application. Is this used to provide accurate location information?

Re:Gee, thanks for the notice (0)

Anonymous Coward | more than 5 years ago | (#26256471)

http://www.timecube.com/ [slashdot.org]
If only we embraced Time cube, we wouldn't have to deal with this nonsense.

Re:Gee, thanks for the notice (0)

Anonymous Coward | more than 5 years ago | (#26255975)

Not exactly the same as you mention, but I wonder. How many applications do you think consider the amount of time passed to be the difference of two time_ts? They will probably be affected by this, if only for a second... Or, perhaps more likely would be that your system doesn't observe these, never syncs with a system that does, and your clock ends up a second off..

Re:Gee, thanks for the notice (2, Insightful)

rew (6140) | more than 5 years ago | (#26255993)

You mean that in a critical field-of-work a system that fails more often than "doesn't work on leap days" gets past the acceptance tests?

I now understand where the pressure to remove leap seconds comes from. From the idiots that can't specify systems that handle them correctly.

Re:Gee, thanks for the notice (0)

MichaelSmith (789609) | more than 5 years ago | (#26256077)

You mean that in a critical field-of-work a system that fails more often than "doesn't work on leap days" gets past the acceptance tests?

Yes, I suppose so

I now understand where the pressure to remove leap seconds comes from. From the idiots that can't specify systems that handle them correctly.

A leap second applied across a distributed system where clocks will slew at different rates is effectively a source of noise. When your noise level increases some degradation of service is inevitable.

Re:Gee, thanks for the notice (1)

rew (6140) | more than 5 years ago | (#26256267)

Excuse me? If everybody supports leap days, and time needs to be accurately kept across systems, then all systems should simply implement leap seconds.

It is not acceptable if some software implements the leap-day as the first day of a leap year. It is only acceptable as the last day of february.

So when a leap second comes about, everybody leaps a second at the same time, and no noise is introduced.

If clocks slew at different rates, they need to be corrected for anyway. So either you run public NTP which will probably give you leap seconds as well, or you run NTP on your private network. This is an out-of-the-box solution, but you could also chose to implement anything again from scratch. Fine.

(I think you're worried about some systems applying it an hour early, and others an hour too late. The idea about leap seconds is that they happen, just like leap days, at a precise specified point in the calendar. Here in Holland we've been through the whole new years thing already by the time the leap second hits: We're at UTC+1. Here the leap second gets added just before 1:00 AM.

If you're worried about there being half a second or so jitter between applications of the leap second, then the problems are 100x less than what apparently exists now when some systems got accepted without support for leap seconds. )

Re:Gee, thanks for the notice (2, Informative)

MichaelSmith (789609) | more than 5 years ago | (#26256391)

A couple of things:
  • The NTP daemon is normally used to interface with GPS clocks and to distribute time around a LAN. It never allows time to just jump. It always slews the clock. My ubuntu desktop system at work took two weeks to slew the time by a couple of hours.
  • As another poster pointed out, POSIX doesn't understand leap seconds the way it understands leap days. The leap second has to be faked by changing the speed of a clock for a while and living with the inconsistency in the mean time.
  • The main problem is with real time systems which continually broadcast their physical state and the time at which that state was correct. When the time starts to slew the system which listens to those messages may think the sender has a fault because the interval between messages seems to have changed (as reported by the sender). You might be trying to get millisecond timing accuracy over a packet switched LAN. To do that you have to rely on time stamps.
  • You just can't use NTP everywhere. Different components will run different OS's, some of which can't run the same NTP software. Some won't have TCP/IP networks to them, like aircraft. GPS is supposed to give the universal time reference. Its just that every now and then, it doesn't do exactly that.

Re:Gee, thanks for the notice (1)

growse (928427) | more than 5 years ago | (#26256509)

I thought NTP could handle leap seconds though? I seem to remember when there was a leap second about 3 years ago looking through the NTP logs and finding an entry saying something like "woohoo an extra second here!" - it just chopped the clock back a second. Could be wrong though.

Re:Gee, thanks for the notice (5, Interesting)

valen (2689) | more than 5 years ago | (#26256057)

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

why rely on hh/mm/ss instead of millis elapsed... (3, Insightful)

Anonymous Coward | more than 5 years ago | (#26256211)

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.

Re:why rely on hh/mm/ss instead of millis elapsed. (0)

Anonymous Coward | more than 5 years ago | (#26256531)

AC gets all the points, thread closed.

Re:why rely on hh/mm/ss instead of millis elapsed. (1)

Gnavpot (708731) | more than 5 years ago | (#26256605)

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.

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.

Re:Gee, thanks for the notice (0)

Anonymous Coward | more than 5 years ago | (#26256489)

This statement is an oxymoron. "Absoulte precise timing" and "Every time we add a leap second we get issues raised".

Raw high precision timing sources are **never** effected by leap seconds and arbitrary decorations.

Re:Gee, thanks for the notice (1)

TheRaven64 (641858) | more than 5 years ago | (#26256573)

Why on earth would you use a calendar date in these systems, rather than a number of seconds from a fixed epoch date? Most computers store the time internally in such a format, as a time_t (which is either a large integer or a double, depending on the system), with the epoch date determined by the system designers. Converting between two such systems is just a matter of adding a fixed offset (the difference between the two epoch dates, in seconds). Converting to a calendar date is more complex, but the only time you do that is for user interfaces.

Re:Gee, thanks for the notice (1)

tyldis (712367) | more than 5 years ago | (#26256203)

The summary gives the impression that they figured this out today. The announcement is just a reminder and a PR magnet.

This has been known for quite some time and is significant for some industries (like my field of work; satellite telemetry).

legally speaking, it's the first leap for the US (5, Informative)

at10u8 (179705) | more than 5 years ago | (#26255697)

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 [ucolick.org].

Re:legally speaking, it's the first leap for the U (0, Troll)

timmarhy (659436) | more than 5 years ago | (#26255765)

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.

Re:legally speaking, it's the first leap for the U (0, Funny)

Anonymous Coward | more than 5 years ago | (#26255777)

If you don't mod this down you are not a patriot.

Re:legally speaking, it's the first leap for the U (5, Informative)

ta bu shi da yu (687699) | more than 5 years ago | (#26255785)

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.

Re:legally speaking, it's the first leap for the U (-1, Flamebait)

Anonymous Coward | more than 5 years ago | (#26255787)

Well, the US is a backwards shitty country, last to join the civilized world.
mod me flamebait if you want, you know it's true

Re:legally speaking, it's the first leap for the U (-1)

Anonymous Coward | more than 5 years ago | (#26255867)

Dammit that's one more second for the Bush administration! Obama please have friendly forces occupy the WHite House pronto!

Re:legally speaking, it's the first leap for the U (1)

bgd73 (1300953) | more than 5 years ago | (#26256195)

"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.

Re:legally speaking, it's the first leap for the U (2, Informative)

Detritus (11846) | more than 5 years ago | (#26256217)

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.

how will my computer know (0)

Anonymous Coward | more than 5 years ago | (#26255727)

HOw will my computer know to add on the extra second? I run the CentOS

Re:how will my computer know (3, Interesting)

TCM (130219) | more than 5 years ago | (#26255959)

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:how will my computer know (0)

Anonymous Coward | more than 5 years ago | (#26256081)

Maybe you should also plug-out your computer, reformat the drive and reinstall your OS.

Re:how will my computer know (0)

Anonymous Coward | more than 5 years ago | (#26256181)

You know, new year, new computer! It all makes sense.

Re:how will my computer know (0)

Anonymous Coward | more than 5 years ago | (#26256589)

Since the leap second is a result of the unpredictable fluctuations in the rotation of the Earth, it can only be measured, not encoded in an algorithm.

If accuracy and precision are important, then people need to learn the difference between time of day and time durations. Time of day is an empirical property which, strictly speaking, isn't divided into fixed length units (except for the "second", which we keep constant with artificial schemes like leap seconds). If you need to measure or specify a duration, don't do so by taking two time of day values.

Longer, or shorter? (4, Informative)

Smoke2Joints (915787) | more than 5 years ago | (#26255757)

"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?

Re:Longer, or shorter? (1)

at10u8 (179705) | more than 5 years ago | (#26255771)

If you're in London, where legal time is still mean solar time, then the legal new year happens in the middle of the UTC leap second.

Re:Longer, or shorter? (2, Funny)

johanatan (1159309) | more than 5 years ago | (#26256171)

Maybe he's assuming that the general population would get this one right and we uninformed nerds would not? :-)

There goes the space-time continuum... (0)

Anonymous Coward | more than 5 years ago | (#26255793)

The Year 2008 + 1sec Bug?

That's UTC (5, Informative)

Bruce Perens (3872) | more than 5 years ago | (#26255805)

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.

You have a chance! (2, Funny)

Anonymous Coward | more than 5 years ago | (#26255819)

If you messed up in 2008 you still have an extra second to make good.

DON'T WASTE THIS GOLDEN OPPORTUNITY!

Re:You have a chance! (0)

Anonymous Coward | more than 5 years ago | (#26255883)

Hey, that extra second could be a time for Slashdotters to get laid. :-).

I'll have to mention this to HR... (5, Funny)

Frosty Piss (770223) | more than 5 years ago | (#26255821)

I work a graveyard shift. You can bet I'll bring this up to the boss. I don't work for free!

Re:I'll have to mention this to HR... (-1, Offtopic)

Anonymous Coward | more than 5 years ago | (#26255925)

You and me both.

Damn Bush (5, Funny)

Anonymous Coward | more than 5 years ago | (#26255871)

Bush will do anything to remain president just a little longer.

Excellent news for my sex life (4, Funny)

unassimilatible (225662) | more than 5 years ago | (#26255873)

I will be able to give my GF an extra round of pleasure, with time to spare.

OK, just kidding - I am a /.'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.

Re:Excellent news for my sex life (5, Funny)

Tablizer (95088) | more than 5 years ago | (#26256017)

I will be able to give my GF an extra round of pleasure, with time to spare.

You'll have to hope for a leap-inch or two before that happens
               

While we're at nitpicking (2, Interesting)

Opportunist (166417) | more than 5 years ago | (#26255877)

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:While we're at nitpicking (1)

sFurbo (1361249) | more than 5 years ago | (#26255943)

Well, the scientific project would have to be long-running and/or non-local if it shouldn't be easier to just define a local time for it. But, as someone already pointed out, this is very important in air traffic control.

Re:While we're at nitpicking (0)

Anonymous Coward | more than 5 years ago | (#26256393)

UTC.

In other words, if you're ahead of that (most of Europe, say), the leap second will only occur AFTER midnight (your local midnight), so you won't have to worry about it for the purpose of hitting exactly the right second to raise your glass.

If you live in the USA, for instance, you're out of luck: you'll have to take the leap second into account.

Added When (1)

Bios_Hakr (68586) | more than 5 years ago | (#26255897)

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?

Re:Added When (0)

Anonymous Coward | more than 5 years ago | (#26255957)

From the summary and TFA, a correct device should display 23:59:59, then 23:59:60, then 00:00:00.

Re:Added When (1)

gmthor (1150907) | more than 5 years ago | (#26256029)

Actually, GPS dosn't know anything about "leap anything". Since the start of GPS not leap seconds or leap days where added to the GPS time because it is to dangerous to switch. See Global_Positioning_System#Timekeeping [wikipedia.org]

Re:Added When (2, Informative)

Barnett (550375) | more than 5 years ago | (#26256177)

Yes, the GPS system uses its own internal GPS time which is different from UTC. But the difference is always exactly an integer number of seconds and the GPS system is made aware of the changes to this difference (like when a leap second is added) so a GPS unit can and should display UTC correctly, ie 59, 60, 00.

Re:Added When (4, Informative)

Detritus (11846) | more than 5 years ago | (#26256127)

The length of the second doesn't change. An extra second is added. I work with precision timing systems where this is an issue.

The sequence is:

23:59:59 UTC
23:59:60 UTC
00:00:00 UTC
00:00:01 UTC

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.

GPS uses its own time scale that isn't affected by leap seconds.

Re:Added When (1)

Barnett (550375) | more than 5 years ago | (#26256143)

Does anyone know of any GPS units that display this correctly? Last time (in 2005) I checked both my Trimble and Garmin and neither displayed the leap second correctly.

Re:Added When (1)

ionix5891 (1228718) | more than 5 years ago | (#26256511)

maybe we should use stardates? they just sound so cool

*read in a Picard voice*
stardate 48182.647... captains log supplemental... #1 is humping my leg... off boy off! ... this Data guy is really freaking me out lately ...

Re:Added When (1)

Gnavpot (708731) | more than 5 years ago | (#26256711)

GPS uses its own time scale that isn't affected by leap seconds.

I don't doubt that it does that internally, but GPS receivers usually put a timestamp on the position. How is this timestamp affected?

Will a GPS receiver continue to convert the internal time to UTC following an outdated algorithm which is hardcoded into the receiver, or is the conversion algorithm part of the data received from the satellites?

In other words: Can we trust the time from a GPS receiver, or will two receivers show a difference of N seconds, depending on how many leap seconds we have had since each GPS receiver was new.

Oops (1)

dufachi (973647) | more than 5 years ago | (#26255937)

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!

Will windows automatically adjust my clock for me? (3, Funny)

extagboy (60672) | more than 5 years ago | (#26255955)

Or, is that only in the vista ultimate edition?

Re:Will windows automatically adjust my clock for (0)

Anonymous Coward | more than 5 years ago | (#26255987)

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.

oh really (1, Funny)

mestar (121800) | more than 5 years ago | (#26255981)

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.

Re:oh really (1)

Tablizer (95088) | more than 5 years ago | (#26256031)

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.

Maybe they feel its easier to take it in small chunks instead of big chunks. If you don't have experience from the last one because it was too long ago, then fowling up minutes is likely to be a bigger problem in most cases than fowling up a second. Plus, it's fairly regular such that an organization can keep fresh on the procedure rather than have to dig people out of retirement.
         

Fluctuations? (3, Interesting)

Woek (161635) | more than 5 years ago | (#26256087)

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...

Re:Fluctuations? (5, Informative)

Nick Barnes (11927) | more than 5 years ago | (#26256151)

I'm sorry? Fluctuations in the rotation of the earth? You mean the earth is accelerating and breaking?

Yes, that's exactly what we mean (well, "braking" rather than "breaking"). The earth does not have a constant angular velocity. To conserve angular momentum, as the mass distribution of the earth changes (e.g. due to glacial rebound), the spinning of the earth speeds up and slows down. It also slows down a little due to tidal braking. So a "day", as measured by the rotation of the earth relative to the fixed stars, is not exactly 86400 seconds. It's generally a little more, around 86400.001 seconds at present, and it varies from day to day and from year to year. Now that civil time (UTC) is kept with atomic clocks, this is a genuine problem. Leap seconds are introduced to keep UTC close to UT1 (astronomical time).

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...

That's right. Leap seconds have nothing whatsoever to do with that. They don't affect the calendar. That's what leap days are for. Leap days keep the calendar in sync with the seasons (by setting the average calendar year length to 365.2425 days, very close to the vernal equinox year which is currently 365.242374 days).

Re:Fluctuations? (4, Informative)

bitrex (859228) | more than 5 years ago | (#26256497)

The redistribution of mass after the 2004 Indian Ocean undersea earthquake was enough to measurably affect the rate of the Earth's rotation; the Three Gorges Dam project will also have a minute effect due to the concentration of water in the reservoir that's formed.

Re:Fluctuations? (1)

Gnavpot (708731) | more than 5 years ago | (#26256681)

the Three Gorges Dam project will also have a minute effect due to the concentration of water in the reservoir that's formed.

Pun intended?

Re:Fluctuations? (1)

berend botje (1401731) | more than 5 years ago | (#26256165)

The leap-second is caused by the rotation around the sun not being exactly 365.25 days.

However, the rotation around the Earths axis isn't all that smooth. It indeed accelerates and breakes due to tidal movements, atmosferic influences and interference with the Earths polar wobble.

The day-to-day difference can be as high as a few seconds, but averages taken over a long(ish) period are very stable. It has to be, conservation of momentum-wise.

Re:Fluctuations? (2, Informative)

Anonymous Coward | more than 5 years ago | (#26256179)

It has nothing to do with the fact that a rotation around the sun is not exactly 365.25 rotations around our own axis?

No, it does not. Leap days are about keeping the calendar in sync with the seasons. Leap seconds are about keeping the clock in sync with the rotation of the earth. These are two different components of motion, and they are handled with different measures.

Leap second at UTC, not Local midnight! (5, Informative)

Terje Mathisen (128806) | more than 5 years ago | (#26256193)

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

This is why (0)

Anonymous Coward | more than 5 years ago | (#26256447)

Scientific clocks need to get off Earth time and just have a clock counting seconds from a certain point in time.

Load More Comments
Slashdot Account

Need an Account?

Forgot your password?

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>
Sign up for Slashdot Newsletters
Create a Slashdot Account

Loading...