Beta
×

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 Seconds' May Be Eliminated From UTC

Soulskill posted more than 4 years ago | from the time-and-time-again dept.

News 470

angry tapir writes "Sparking a fresh round of debate over an ongoing issue in time-keeping circles, the International Telecommunications Union is considering eliminating leap seconds from the time scale used by most computer systems, Coordinated Universal Time (UTC). Since their introduction in 1971, leap seconds have proved problematic for at least a few software programs. The leap second added on to the end of 2008, for instance, caused Oracle cluster software to reboot unexpectedly in some cases."

cancel ×

470 comments

Sorry! There are no comments related to the filter you selected.

Hmmm (5, Funny)

HappyClown (668699) | more than 4 years ago | (#33351428)

Now waaaaaait just one second! Oh, scratch that...

Re:Hmmm (-1, Flamebait)

Anonymous Coward | more than 4 years ago | (#33351936)

Listen, Clown, how big is your COCK? Because I hear it's fucking TINY, as in about the size of a 10 year old with a woody. Is it true?

Stupid (2, Interesting)

Anonymous Coward | more than 4 years ago | (#33351452)

Yeah, leap seconds suck, but the proposed solution (to let UTC drift farther and farther away from reality) sucks even harder. UTC should just be abolished in favor of UT1. Computer clocks are so crude anyway (mine is off by 3 seconds right now) that the supposed benefits of UTC's constant second are really non-existent, every computer needs to have its time adjusted now and then no matter what.

Re:Stupid (4, Informative)

tagno25 (1518033) | more than 4 years ago | (#33351534)

Yeah, leap seconds suck, but the proposed solution (to let UTC drift farther and farther away from reality) sucks even harder. UTC should just be abolished in favor of UT1. Computer clocks are so crude anyway (mine is off by 3 seconds right now) that the supposed benefits of UTC's constant second are really non-existent, every computer needs to have its time adjusted now and then no matter what.

And that is what NTP is for. To automatically adjust the computers clock to account for drift.

Re:Stupid (0)

Anonymous Coward | more than 4 years ago | (#33351630)

try asking ten supposedly-authoratative NTP servers what time it is right now

Re:Stupid (3, Informative)

mikael_j (106439) | more than 4 years ago | (#33351746)

Well, if you tell your NTP client to use those ten servers for setting the time chances are your computer's clock will be very accurate.

Re:Stupid (-1, Troll)

Wowsers (1151731) | more than 4 years ago | (#33351996)

Who cares what they do with UTC, I'm bigging up GMT (at great risk of troll mods). You all use UTC because you can't stand being reminded it's GREENWICH Mean Time, a UK concept of time that stuck around the world.

Oracle sholuld simply fix their software... (2, Insightful)

zebslash (1107957) | more than 4 years ago | (#33351454)

Isn't the problem with Oracle here? It should not be that difficult to fix their software. What's the difference with Summer time change?

Re:Oracle sholuld simply fix their software... (5, Informative)

nacturation (646836) | more than 4 years ago | (#33351514)

Isn't the problem with Oracle here? It should not be that difficult to fix their software. What's the difference with Summer time change?

The difference with spring/fall time changes is that although the local time may change, the UTC time does not. In other words, your offset from UTC (eg: GMT-8) may get adjusted depending on your location's observance of daylight savings time but UTC itself simply marches on oblivious to anything. The leap second is the one exception.

Re:Oracle sholuld simply fix their software... (3, Interesting)

carini (555484) | more than 4 years ago | (#33352036)

Insted of using "leap" seconds why NTP dosn't use a longer interval to adjust the time in small steps?. With 1/1000s adjustment every 1024 seconds (which is the polling interval for most stable ntp client) the leap seconds adjustment need less than 2 week to complete.

Re:Oracle sholuld simply fix their software... (1)

mysidia (191772) | more than 4 years ago | (#33351650)

Definitely. Oracle is not so big that even time itself should bend to their will.

Leap seconds have value in that they keep the UTC consistent with localtime, having only a number of hours offset.

Can you imagine how complicated things will get when we need to define time zones as -0X000+5seconds UTC?

Re:Oracle sholuld simply fix their software... (0)

Anonymous Coward | more than 4 years ago | (#33351860)

What we should fear is if Oracle patent the idea of software crashing due to leap seconds bugs. You all know companies start to sue when all their innovation is gone.

Poor solution (5, Insightful)

LostMyBeaver (1226054) | more than 4 years ago | (#33351456)

The proper solution is to make programmers aware of leap seconds. There are 86400 seconds in a normal day, however there is an additional second added once or twice a year to adjust for solar time.

Wikipedia documents it quite well and programmers in modern times should be heading to wikipedia almost constantly anyway. The real problem occurs when the date/time is given in seconds since an "event" such as Jan 1, 1970. Most programmers don't know about leap seconds and I must admit, I don't generally bother calculating for them. But if it were necessary, it would be relatively trivial to do so.

We shouldn't remove fixes to the clock just because programmers are undereducated. I'm quite convinced that just posting this on Slashdot will raise awareness across a high percentage of the programming world.

I also always wondered why undergraduate studies for computer science didn't make time a relevant issue. It seems as if it's one of the more complex topics and yet, we don't pay any attention to it. Last formal education I had on time (not talking about physic related, but calendar) was in primary school. There are so many time systems out there that we should pay more attention to educating programmers on it.

Re:Poor solution (1, Insightful)

mrnobo1024 (464702) | more than 4 years ago | (#33351478)

Christ, as if programmers don't have enough damn complexity to deal with already. For the purposes of timekeeping, a second should just be defined as 1/86400 of a day. There, problem solved, we never have to screw with the calendar again for thousands of years.

Re:Poor solution (2, Informative)

Anonymous Coward | more than 4 years ago | (#33351496)

But the reason we need leap seconds is because "a day" is changing. The earth's rotation is slowing.

Defining a fundamental physical unit in terms of a moving target isn't a fantastic idea.

Re:Poor solution (0, Troll)

mrnobo1024 (464702) | more than 4 years ago | (#33351552)

So let the length of the day change, and let the second change with it.

Physicists can continue to use the constant cesium-133-defined second, let's call it the "SI second", for measurements when they need precision. But why does the SI second need to exactly equal the time_t second? I can't think of any reason.

Re:Poor solution (3, Funny)

dcollins (135727) | more than 4 years ago | (#33351810)

I nominate you to write the interface between the physicists' Geiger-counter measuring "SI-seconds" in an experiment, and the computer software that works in "time-t-seconds", accounting for all the past & future history of changed time-t-seconds. Sounds so simple.

Re:Poor solution (0)

mrnobo1024 (464702) | more than 4 years ago | (#33351872)

The difference between atomic time and solar time is minuscule compared to the inaccuracy of a typical computer clock. No physicist would be using their computer clock for anything that requires serious precision.

Re:Poor solution (2, Informative)

chaboud (231590) | more than 4 years ago | (#33351940)

One clock has to win, but simple things like file times/dates for saving trace data, network behavior, and exceedingly long runs could be a real pain with an SI second and magical 86400th second.

Worse, before you do any of this, you'd better be able to tell us in advance how long every day is going to be.

This is as daft an idea as making each day 1/365th of a year, damn the consequences. We'll be catching lunch in the dark.

Re:Poor solution (0)

Anonymous Coward | more than 4 years ago | (#33351898)

I nominate you to write the interface between the physicists' Geiger-counter measuring "SI-seconds" in an experiment, and the computer software that works in "time-t-seconds", accounting for all the past & future history of changed time-t-seconds. Sounds so simple.

The overwhelming majority of programmers are not solving such problems and therefore do not care.

There is no reason why the overwhelming majority of programmers should be forced to factor in something ultimately impossible to plan for like leap seconds when the complexity adds no benefit whatsoever for what it is they are trying to do, ie solve a business problem.

It doesn't make a shit of a difference if the customer's order comes in at 4:36:37pm or 4:36:38pm. Forcing someone working on such a system to care about leap seconds is a colossal waste of time in over-engineering, and programmers should not have to care about it unless what they are doing specifically requires such precision.

There are orders of magnitude more programmers working on mundane ordering, inventory management, data processing applications than there are working on Geiger counter interfaces and Mars rover logic units.

Re:Poor solution (1)

indeciso (1350357) | more than 4 years ago | (#33351986)

Great, then every time the second definition changes, we can get rid of our old watches, clocks, motherboards, cell phones, and any other stuff we use to measure time, cause they're going to be outdated and defective. Sounds like a great idea to activate the economy with some extra sales! [sarcasm mode off]

Anyway, what's the reason why we'd need an invariable "SI second" if nobody would use it?

Re:Poor solution (4, Interesting)

LostMyBeaver (1226054) | more than 4 years ago | (#33351578)

Nobo has a point... but it would make it so that the hardware engineers would suffer instead of the software ones. 1/86,4000 of a day = 1 second could be a fair solution. All we would need to do then would be to come up with a new atomic clock which allows for the alteration and then come up with computer crystals that are accurate to the new system (hey, let's get ones that are accurate to begin with, that would be great).

But, since respectable companies tend to run their own SNTP servers and they themselves adjust against national servers (we hope), it could simply be a good idea to ditch the leap second in favor of fixing all the clocks.

But, I think the real issue of the article is the occasions where "17:59:60" is a valid time. I think for presentation (and databases), it would in fact have been better to simply prolong 17:59:59 or progressively added a millisecond for the next 1000 seconds for example. Although it might through off scientific calculations during that period, the impact would be less critical.

Re:Poor solution (0)

Anonymous Coward | more than 4 years ago | (#33351634)

the issue is that time delta should not be computed by asking utc because that's not constant.

every os has a 'timer' that's already utc-compliant. use that to compute time delta and be done with it.

Re:Poor solution (1)

TapeCutter (624760) | more than 4 years ago | (#33351670)

Sorry but that's an "april fools" soultion, it won't fix calender drift and it would screw up physics. The second is the SI unit of time, it's definition has nothing to do with the motion of the Earth.

Re:Poor solution (1)

mrnobo1024 (464702) | more than 4 years ago | (#33351796)

The SI second should continue to be what it's been since 1967: 9,192,631,770 periods of the radiation corresponding to the transition between the two hyperfine levels of the ground state of the caesium-133 atom. But there's no reason such an arbitrary unit needs to be part of our calendar.

It's bad enough that the day doesn't fit into the year evenly -- there's no way around that, so we need leap days to fix it. But why do we have to introduce another annoyance, one that is even worse as it needs constant maintenance (unlike the leap-day system which hasn't needed adjustment since 1752), by trying to shoehorn the SI second into the day? As far as I can tell, this accomplishes nothing but making life harder for people.

Re:Poor solution (0)

Anonymous Coward | more than 4 years ago | (#33351854)

I don't see it making life harder for most people - the only people it would be harder for is programmers involved in timekeeping, for whom understanding the leap second is a part of their job. 99% of the population either won't be bothered by a drift of a few seconds in their lifetime or will let it be corrected by whoever they synchronise their clocks with (e.g. central servers).

Splitting the second into "real seconds" and "sort-of seconds" is just going to confuse things.

Re:Poor solution (1)

TapeCutter (624760) | more than 4 years ago | (#33351970)

How do you define a "day"? If you use the sun from zenith to zenith then depending on where you are in the yearly orbit that value can vary by ~8 seconds either side of the average (24hrs). So now you have the problem of calibrating the vibrating crystal in your clock to something that is not only abitrary (zenith to zenith) but also changes depending on the season (24hrs +/- 8 seconds).

Re:Poor solution (1)

mrnobo1024 (464702) | more than 4 years ago | (#33352020)

How do you define a "day"?

UT1 [wikipedia.org] is as good a definition as any.

Of course it's impossible to calibrate a crystal timer to match solar time exactly, because it's impossible to calibrate a crystal timer to match anything exactly. My clock is already 4 seconds behind time.gov and that's with it being synchronized periodically. Computer clocks don't need to change a bit, because it wouldn't do any significant amount of good anyway.

Re:Poor solution (1)

Eivind (15695) | more than 4 years ago | (#33351832)

A day isn't constant length.

Sounds fairly complex to me, to deal with a second in 1900 being a different time-period from a second in 2000.

Re:Poor solution (2, Interesting)

toastar (573882) | more than 4 years ago | (#33351502)

Why adjust for solar time?

if you were to count the number of days since the 0AD, Would you ignore leap days? UTC is a count of seconds since a specific time. All computers do is count time. It's the user interface that should adjust for leap seconds when it converts to local time.

Why can't Computer people and farmers use different time metrics?

Re:Poor solution (1)

olden (772043) | more than 4 years ago | (#33351660)

There's really no need to redefine UTC -- especially if it's just because some programmers are ignorant of alternatives.
Absence of leap seconds is exactly what already-existing scales like TAI [wikipedia.org] are for.

Re:Poor solution (5, Insightful)

Thorsett (5255) | more than 4 years ago | (#33351692)

Why adjust for solar time?

We adjust for solar time because UTC is an astronomical timescale, not a "count of seconds since a specific time." If "computer people" want a timescale that ignores leap seconds, they can use an atomic timescale like TAI (or GPS time, which is a constant offset from TAI). But choosing to standardize the internet on UTC and then complaining it is too hard to do the programming right is a little like buying a house next door to a turkey farm and complaining about the smell.

Re:Poor solution (1)

Odinlake (1057938) | more than 4 years ago | (#33351784)

mod parent up.

Re:Poor solution (1)

at10u8 (179705) | more than 4 years ago | (#33351836)

There is no international regulation which specifies either TAI or GPS time, and the agencies which provide those do not want such regulation. For those who are constrained by regulation, only a time scale specified by the ITU-R will suffice.

Re:Poor solution (1)

Hognoxious (631665) | more than 4 years ago | (#33351786)

if you were to count the number of days since the 0AD

You'd get very confused - there was no 0 AD (or BC for that matter).

1 BC was followed by 1 AD.

Re:Poor solution (3, Informative)

toastar (573882) | more than 4 years ago | (#33352008)

if you were to count the number of days since the 0AD

You'd get very confused - there was no 0 AD (or BC for that matter).

1 BC was followed by 1 AD.

Well if you want to get technical it was neither.

I think it was called 753 AUC

Re:Poor solution (2, Interesting)

at10u8 (179705) | more than 4 years ago | (#33351816)

The reason we adjust for solar time is that two standing international agreements demand that we define the day [ucolick.org] as a "mean solar day". Computer people and farmers can use different times if mean solar days are not made illegal and replaced with atomic days, that's what zoneinfo is for [ucolick.org] .

Re:Poor solution (2, Interesting)

TapeCutter (624760) | more than 4 years ago | (#33351602)

"I also always wondered why undergraduate studies for computer science didn't make time a relevant issue."

They did when I was at uni, I'd never heard of leap seconds or the 100yr & 400yr rules for leap days until I had to redo the same dammned calender assignment every time a new language was introduced.

Re:Poor solution (0)

Anonymous Coward | more than 4 years ago | (#33351716)

Is it really that hard? Under the hood, computers are only storing elapsed ticks, so for comparing times internally there's no problem. The only problem leap seconds create is in displaying those counts in human terms, which in a great many cases doesn't need exact-to-the-second accuracy, since it's just displaying a timestamp and every second is still unique even if the displayed labels are technically wrong by a few seconds.

For things where you DO need the label to be correct, you should be able to do it with a list of the timestamps of all past leap seconds (and keep it updated with future planned leap seconds as they're announced. Hmm. Would be great if that was a standardized little table provided by the OS and kept automatically updated. I wonder if that already exists?). In practice you'd want a data structure a little nicer than just a bland sorted array of timestamps, so you do certain lookups faster/easier; you could generate such things from the list, of course. Like a precalculated list of timestamps of the first second of each year would be nice for Important Things that absolutely must roll over exact at the year boundaries; that'd have all the past leap seconds 'baked in' already. Likewise a month one for month boundaries. Paired with a "what are the leap seconds for year X" table, you should be able to generate the human date for any timestamp without much code.

Re:Poor solution (1)

Chuck Chunder (21021) | more than 4 years ago | (#33351974)

Is it really that hard?

It isn't hard if you think about it.

If you haven't thought about it and a "60" appears where you only anticipating 0-59 then the results could presumably be surprising!

I doubt that very many people actively consider that possibility but in most cases get away with it because it doesn't really matter to their code because they are just recording or displaying a time, rather than doing any particular calculations on it.

Maybe not... (1)

bradley13 (1118935) | more than 4 years ago | (#33351736)

The last thing we want is every programmer inventing his or her own way to deal with this - imagine the mess of mutually incompatible implementations. Moreover, just how do you propose to change time-validation code to accept 23:59:60? With leap-days, it is quite clear when February 29th is acceptable and when not (and look how many people still get it wrong!). With leap-seconds, there are no rules. Just imagine the myriad of ways creative people will be able to foul this up! Leap seconds should be completely ignorable for everyone outside of physics and astronomy. They should disappear into routine time-corrections from the central time servers.

Re:Poor solution (1, Insightful)

Anonymous Coward | more than 4 years ago | (#33351766)

Parent poster is quite correct. The second used to be based on the rotation of the earth. The earth is very gradually slowing down. Therefore the second defined by the rotation of the earth is changing, so it is not a satisfactory physical unit. The second is now defined in a manner which is more stable than the rotation of the earth. Once you have a second which is sufficiently accurate to successfully measure the slowing of the earth, then leap seconds become inevitable.

The alternative would be to continually change the definition of the second, which would cause the whole system of physical units to be continually changed. A whole bunch of physical constants would no longer be constant. Doing physics would become near impossible. That would be a very foolish course of action.

Programmers need to grow up. Leap seconds are here to stay. This is an unfortunate case of the general problem of programmers needing adult supervision.

Re:Poor solution (1)

Lord Bitman (95493) | more than 4 years ago | (#33351794)

non-idiot programmers use a library for this sort of thing. Solve it ONCE.

Re:Poor solution (0)

Anonymous Coward | more than 4 years ago | (#33351804)

Letting the programmer take care of the problem is all nice and well. It also works for well for CompSci. where the case usually is that someone else pays for the hardware.
When you have a microcontroller with about 2k program space and 128 byte sram you'd rather not make the time calculation needlessly complex.
Sure, you could just buy a larger controller but for larger product series this could easily strip $1M from your profit and possibly bring the project to a no-go.
There are a lot of things that must keep time out there, your average computer is in minority there. Having a complex method to keep an accurate time might be ok, but if it cannot be easily be implemented in a way that has roughly second precition then I wouldn't bet on it being a popular standard.

Re:Poor solution (1)

Zoxed (676559) | more than 4 years ago | (#33351828)

> The proper solution is to make programmers aware of leap seconds. There are 86400 seconds in a normal day, however there is an additional second added once or twice a year to adjust for solar time.

You should have checked your favoured Wikipedia first (!!): leap seconds *can* be added in June or December but they are actually only needed every few years, and none have been added for some time.
(When I studied Computer Studies I did not learn about Leap Seconds. But when I started in the space industry that required Leap Seconds to be accounted for I was told about them.)

The best solution is a robust solution (3, Interesting)

Chuck Chunder (21021) | more than 4 years ago | (#33351830)

I think it makes absolutely no sense for most computers or programmers to have to account for leap seconds.

The reality is that computers already have to allow for their clock drifting from universal time, that's why we have NTP. There's no point getting individual computers account for leap seconds, it would be easier and less error prone if reference clocks transparently accomodate leap seconds (ie without sending a 23:59:60 to the world) and everyone else can just drift back in sync with them when one occurs.

There may be a few applications where a computer really does need to accomodate leap seconds (such as a reference clock!) but for the rest of us the additional complexity gives no advantage whatsoever.

Re:The best solution is a robust solution (1)

shird (566377) | more than 4 years ago | (#33351924)

This exactly. Even if they didn't correct their clocks through NTP or other means, their clocks would only be slow by about 10 seconds or so over the course of 50 years. The servers/desktop PCs are likely to have been rebooted a few times in those 50 years, so they can correct the clocks in that downtine if they really must. As you mentioned, clock drift and corrections via NTP make thinking about implementations of 'leap seconds' for end user software a waste of time.

Re:Poor solution (1)

RAMMS+EIN (578166) | more than 4 years ago | (#33351858)

``I also always wondered why undergraduate studies for computer science didn't make time a relevant issue. It seems as if it's one of the more complex topics and yet, we don't pay any attention to it.''

I couldn't agree more. Now that most programmers I know have moved on from languages with broken type systems and manual memory management, one of the few recurring issues I see in every project is time. Time zones, in particular, often aren't specified, or not picked up by people reading the specification. Same goes for time formats. And then there are people who forget to arrange for their clocks to be synchronized with the rest of the world, leading to wildly incorrect system times. It's almost a given that exchanging time information will cause trouble.

And that's without getting into the _actually_ difficult stuff, such as adding a number of years to a time format expressed as a number of seconds, or implementing a program that will perform some computation periodically, without drifting away from synchronized time.

Re:Poor solution (1)

Penguinisto (415985) | more than 4 years ago | (#33351884)

I also always wondered why undergraduate studies for computer science didn't make time a relevant issue. It seems as if it's one of the more complex topics and yet, we don't pay any attention to it. Last formal education I had on time (not talking about physic related, but calendar) was in primary school. There are so many time systems out there that we should pay more attention to educating programmers on it.

Time-keeping and even leap-seconds are covered as far back as the frickin' K&R*. A sibling mentioned the ancient (and for some odd reason still dreaded) calendar and timer exercises that a huge chunk of CompSci students have had to face. It's not like leap seconds are some sort of big and sudden surprise that just popped up in the last couple years (now their implementation schedule seems to be, but still...)

* My copy (2nd ed.) is at home, but I'm somewhat sure that sure someone on /. can reference one quick enough to confirm/deny/whatever...

Re:Poor solution (1)

Penguinisto (415985) | more than 4 years ago | (#33351894)

I also always wondered why undergraduate studies for computer science didn't make time a relevant issue. It seems as if it's one of the more complex topics and yet, we don't pay any attention to it. Last formal education I had on time (not talking about physic related, but calendar) was in primary school. There are so many time systems out there that we should pay more attention to educating programmers on it.

Time-keeping and even leap-seconds are covered as far back as the frickin' K&R*. A sibling mentioned the ancient (and for some odd reason still dreaded) calendar and timer exercises that a huge chunk of CompSci students have had to face. It's not like leap seconds are some sort of big and sudden surprise that just popped up in the last couple years (now their implementation schedule seems to be, but still...)

* My copy (2nd ed.) is at home, but I'm somewhat sure that sure someone on /. can reference one quick enough to confirm/deny/whatever...

Oracle (5, Interesting)

Anonymous Coward | more than 4 years ago | (#33351460)

Perhaps Oracle should concentrate more on making their software reliable, and less on lawsuits.

From what I recall Digital VMS didn't have that problem, and even had no problems migrating an always on system over different processors, and keeping the cluster running over more than 15 years. One second and Oracle crashes.

It's a pity which of those companies survived.

Re:Oracle (2, Interesting)

williamhb (758070) | more than 4 years ago | (#33351956)

Perhaps Oracle should concentrate more on making their software reliable, and less on lawsuits.

From what I recall Digital VMS didn't have that problem, and even had no problems migrating an always on system over different processors, and keeping the cluster running over more than 15 years. One second and Oracle crashes.

It's a pity which of those companies survived.

Speaking empirically (and somewhat cheekily), isn't the lesson from your example that Digital should have concentrated less on making their software reliable, and more on lawsuits, in order to survive then?

Faulty Software (1)

bysin (173686) | more than 4 years ago | (#33351470)

The issue is the faulty time implementation in software, not time itself.

The problem with leap seconds... (4, Informative)

NixieBunny (859050) | more than 4 years ago | (#33351482)

They aren't predictable in advance. They are basically the noise in the solar system's timekeeping. It's impossible to write code that knows in advance when they will occur, since they are only announced six months ahead of time. So any clock that wants to stay in sync with UTC must be connected to either NTP or GPS or similar timekeeping service.
If only those darn astronomers didn't care so much about keeping the sun at Greenwich precisely at the meridian at high noon, we wouldn't have this problem.

Re:The problem with leap seconds... (5, Funny)

joe_frisch (1366229) | more than 4 years ago | (#33351640)

We could fix this tricky programming issue by regularly adjusting the earth's orbit....

Re:The problem with leap seconds... (1)

Undead Waffle (1447615) | more than 4 years ago | (#33351876)

Might as well fix global warming too while we're at it. Anyone have $40 billion for an Annihilatrix?

Re:The problem with leap seconds... (0)

Anonymous Coward | more than 4 years ago | (#33351696)

How about if all the people in the appropriate hemisphere jumped at the same time?

Re:The problem with leap seconds... (1)

Yvanhoe (564877) | more than 4 years ago | (#33351768)

It seems reasonable to say that a computer program that needs to stay precise to the second on a several years interval must have a NTP or GPS.
It seems reasonable in such case to add a test in your test suite to acknowledge for the "one leap second event on 31th of december"

Re:The problem with leap seconds... (0)

Anonymous Coward | more than 4 years ago | (#33351770)

So any clock that wants to stay in sync with UTC must be connected to either NTP or GPS or similar timekeeping service.

...except GPS time already doesn't follow leap seconds.

Re:The problem with leap seconds... (1)

chichilalescu (1647065) | more than 4 years ago | (#33351778)

6 months in advance is not enough?

Re:The problem with leap seconds... (1)

wvmarle (1070040) | more than 4 years ago | (#33352028)

You don't have any software running on your system that is more than six months old?

Re:The problem with leap seconds... (1)

at10u8 (179705) | more than 4 years ago | (#33351840)

Neither are changes to civil time as decreed by local authorities predictable, but zoneinfo manages to handle the problem. If leap seconds went into zoneinfo with the underlying time_t being uniform then the handling of leaps would be in user space, not in kernel space.

Re:The problem with leap seconds... (0)

Anonymous Coward | more than 4 years ago | (#33351972)

Your solution, if I understood it correctly, would make things easier for Oracle and harder for thousands and thousands of pieces of software that would need handle timezones like "UTC + 2h - 5s"

Re:The problem with leap seconds... (1)

asifyoucare (302582) | more than 4 years ago | (#33351980)

It's impossible to write code that knows in advance when they will occur, since they are only announced six months ahead of time....

So don't. Use the API supplied by the OS or VM. This is the vendor's responsibility. No application code should be trying to figure out when leap seconds occur, and conversely no application code should be assuming the leap seconds don't occur - e.g. applications should do something this :

GregorianCalendar sameTimeTomorrow = thisTime.add(Calendar.DAY, 1);

rather than this :

GregorianCalendar sameTimeTomorrow = thisTime.add(Calendar.SECOND, 86400);

Additionally, always try to work with the date/time API rather than performing calculations with milliseconds since 1970 or tens of nanosends since 1601 or whatever.

It doesn't help that OS and VM vendors always take several versions to do dates and times correctly. It looks simple at first glance but it really isn't.

Re:The problem with leap seconds... (1)

wvmarle (1070040) | more than 4 years ago | (#33352010)

I wonder where the real problem lies... is it that the software encounters an illegal time? Then the software writer should account for that possibility: this can be called a bug as the "illegal time" is in fact legal. Or is there something else, like the application trying to count seconds since a certain time and then running into a mismatch with the system software? Again something that can and should be fixed on application level.

To me it seems to be very much something that software programmers that are working with time on a level that leap seconds are an issue, should know about. And thus be able to account for that they may happen - without knowing in advance when it will be.

Sweeping the issue away? (0)

Anonymous Coward | more than 4 years ago | (#33351490)

I guess for some train timetable the question of using UT or UTC will be quite interesting in 20 years (when the difference is 15 seconds). Abandoning the leaps seconds for a millenium seems a way to make the issue hide from our sight, but then we need to abandon using anything non-UTC-based for timetables.

And imagine "the problem of leap hour" - Y2K will pale...

fashion (-1, Offtopic)

Anonymous Coward | more than 4 years ago | (#33351494)

Online sell fashion goods,Accept PayPal.cheap replica fashion goods for sale from china free shipping Cheap replica handbag [didtrade.com]
Purse handbags [didtrade.com]
wholesale replica handbags [didtrade.com]
Handbags wholesale [didtrade.com]
Cheap Replica watches [didtrade.com]
Cheap LV handbag [didtrade.com]
Cheap Replica Jeans [didtrade.com]
Wholesale Replica Jewelry [didtrade.com]
Cheap replica handbag [didtrade.com]
wholesale fashion handbags [tradeshown.com]
cheap coach handbags [tradeshown.com]
replica designer handbag [tradeshown.com]
replica handbag free shipping [tradeshown.com]
replica handbag accept paypal [tradeshown.com]

Re:fashion (-1, Offtopic)

Anonymous Coward | more than 4 years ago | (#33351788)

Online sell fashion goods,Accept PayPal.cheap replica fashion goods for sale from china free shipping
Toxic crap [didtrade.com]

defective merchandise [didtrade.com]

Made from poisonous plastic [didtrade.com]

Credit card scam. Card numbers resold. [didtrade.com]

Watches that turn your skin green. [didtrade.com]

handbag that falls apart. [didtrade.com]

toxic jeans [didtrade.com]

chipped fakes [didtrade.com]

bad quality [didtrade.com]

overpriced poor quality [tradeshown.com]

cheap coach handbags [tradeshown.com]

Spammer you should not do business with. [tradeshown.com]

toxic plastic handbags. [tradeshown.com]

paypal fraud [tradeshown.com]

FTFY

warp (0)

Anonymous Coward | more than 4 years ago | (#33351512)

OMG !

please twist reality so that software developper won't make errors ? THAT's the idea ?

Considering people I work with are still today unable to get the proper week number in a given year in their applications, I understand the leap second can be a hassle, yet it does exist for a reason.

Who remembers that 1900 and 2100 weren't and won't be bissextile ?

Rules exist and govern the world. When implementing them, first thing is to get to know them.

Changing time because of Oracle? (4, Insightful)

koinu (472851) | more than 4 years ago | (#33351520)

Leap seconds are handled well, when the system supports it well and the software is not utter crap.

I am always annoyed when people break basic things to make software work (e.g. hardware, also see ACPI). Now they are not only breaking hardware, but redefining measurements to make buggy software work. What comes next?

I can understand when something is changed for convenience purposes (to have simpler calculations), but justified with buggy software is plain wrong. And I surely don't care if an Oracle database "reboots"... whatever that might mean.

More Complication (0)

Anonymous Coward | more than 4 years ago | (#33351522)

I, for one, like the idea of being able to take a the UNIX time of event one and subtract the UNIX time of event two to get the elapsed time. Keep it simple. But it won't be simple because making the change now still means pre-2010 will be handled differently, so I'm not sure this is a good idea.

Re:More Complication (1)

Lord Bitman (95493) | more than 4 years ago | (#33351934)

I like the idea of being able to take the IP address of one workstation, and subtract the IP address of another workstation to get the number of people sitting at the same table. But I don't, because that's not what it means and it's not what it should mean.

Time Zones... the stupidest idea ever conceived (0)

Anonymous Coward | more than 4 years ago | (#33351526)

This is a good move but really the whole time system is messed up. Our current system has timezones which extends a flat-earth mentality and pretends like the world has 24 sides (except in Canada where they have 30 minute timezones). Your location should have nothing to do with time, it's absurd that we still have timezones.

China had the right idea -- no timezones in that country.

Re:Time Zones... the stupidest idea ever conceived (1)

scdeimos (632778) | more than 4 years ago | (#33351686)

except in Canada where they have 30 minute timezones

Don't forget Nepal with its 15-minute offset (currently UTC+0545).

Re:Time Zones... the stupidest idea ever conceived (1)

_merlin (160982) | more than 4 years ago | (#33351900)

You need timezones simply so that businesses, schools, etc. located close together (in longitude) can agree on opening times. It would be far more complex if you didn't have time zones.

Anonymous Coward. (0)

Anonymous Coward | more than 4 years ago | (#33351540)

It's all well and good to blame developers, but what about when the definition of time itself we have to work with frequently doesn't account for them (i.e. Unix time).
http://en.wikipedia.org/wiki/Unix_time

Why not get rid of leap year correction? (1)

MessageDrivenBean (534518) | more than 4 years ago | (#33351566)

While we are at it, why don't we get rid of leap year correction at all? Why do we still have leap year correction? I mean, 1 day every 4 years means a month every 120 years means a season shift every 360 years. People won't notice it during their 'normal' lifespan (apart from cryonics). What benefits does the leap year correction itself bring? What unforeseen consequences will occur when the leap year correction isn't applied anymore? Why is it important to have a perfect "seasonal year"/"seasonal calendar"?

Re:Why not get rid of leap year correction? (1)

ekran (79740) | more than 4 years ago | (#33351576)

I think that the major benefit is that you don't have to worry about experiencing snowfall in July (unless you live really far North.)

Re:Why not get rid of leap year correction? (0)

Anonymous Coward | more than 4 years ago | (#33351656)

Or South.

Re:Why not get rid of leap year correction? (1)

MavEtJu (241979) | more than 4 years ago | (#33351592)

Have a chat with Mr Julian and Mr Gregorian.

Re:Why not get rid of leap year correction? (1)

Trepidity (597) | more than 4 years ago | (#33351878)

That's Julius Caesar and Pope Gregory XIII to you.

Re:Why not get rid of leap year correction? (1)

WoRLoKKeD (1142351) | more than 4 years ago | (#33351644)

What unforeseen consequences will occur when the leap year correction isn't applied anymore?

Oh sure, give them ideas. This was probably what caused the systems in Black Mesa to go wrong.

You may well have just doomed us all.

The root of the problem (4, Funny)

Joosy (787747) | more than 4 years ago | (#33351582)

The original article has a quote from one person who sees through the mess to the root of the problem:

The revision "doesn't resolve the underlying geophysical issue"

Simply resolve the "underlying geophysical issue" and the problem will be solved.

Re:The root of the problem (1)

scdeimos (632778) | more than 4 years ago | (#33351694)

Yes, let's use rockets to make the earth spin slightly faster so it keeps up with UT. :)

Re:The root of the problem (1)

sznupi (719324) | more than 4 years ago | (#33352032)

Wouldn't really work with an exhaust confined to the atmosphere; a bit like blowing into the sail of a boat in which you stand.

If not for that small problem - we finally could have some use of all those nuke stockpiles... (nuclear detonations on west sides of steep mountains near the equator would be probably the closest to practical method)

PS. Aren't we launching space rockets primarily in the "wrong" direction? Did I find the culprit? ;)

Ok... (5, Insightful)

Chyeld (713439) | more than 4 years ago | (#33351586)

Isn't this like legislating that PI is 3.14 because some people have problems with the idea of irrational numbers? If programs have issues with leap seconds, it sounds like programs weren't written properly, not that the spec needs to be rewritten to accommodate this flaw. Would these same people have demanded that it be 1999 again to avoid all the costs of the Y2K fixes?

Unreliable (0, Troll)

Khyber (864651) | more than 4 years ago | (#33351628)

"The leap second added on to the end of 2008, for instance, caused Oracle cluster software to reboot unexpectedly in some cases."

And people wonder why I tell them to avoid Oracle at all costs.

They don't have the team to debug-test this crap, they *ONLY* test for running functionality.

I got hit by this bug - it cost me half a million dollars.

If you use Oracle software, you're a total fool.

Re:Unreliable (3, Interesting)

dakameleon (1126377) | more than 4 years ago | (#33351846)

So you knew that leap seconds should be tested for, did you?

I'm not defending Oracle, but at least give them this much credit - leap seconds don't exactly spring to mind when you're planning a test suite for software. Certainly after this incident I can't imagine they would miss it again, but I'd have been surprised if anyone can claim they knew to test for these beforehand.

This is Bull* ... (2, Interesting)

garry_g (106621) | more than 4 years ago | (#33351700)

Sounds to me like some programmers are putting the blame on anyone else than themselves ... I'm wondering, how do computer systems cope with re-syncing the local clock with a remote time source, e.g. NTP server? Computer RTCs are _never_ exact, so updating the local time is necessary in regular intervals, which will always lead to time jumps of milli-, micro- or even complete seconds and more. If your software can't cope with that, fix your software, but don't expect the universe will adapt to fix your shortcomings!

the problem will not go away even without leaps (3, Informative)

at10u8 (179705) | more than 4 years ago | (#33351708)

The historical record of time_t is already ambiguous [ucolick.org] and cannot be corrected by abandoning leap seconds. There is a way to get leap seconds out of the kernel and into user space [ucolick.org] which amounts to reclassifying them as decrees of change of civil time and putting them into zoneinfo while letting the broadcast time scale not have leaps. It's a matter for posterity whether the word "day" will be re-defined by the ITU-R, changed from the current treaty-specified "mean solar day" to a technically-defined "atomic day".

why not give people the option (1)

bugs2squash (1132591) | more than 4 years ago | (#33351752)

That is utc with choice of correction factors. Never more than 10ns correction but at unpredictable times, a few 100s of ns every week at midnight (old UTC) on Sunday or an occasional annual update of a few seconds. Pick the update scheme that suits your situation best. They could be called UTCa, UTCb etc. To most people that don't care, it will all still be UTC.

Invalid Assumptions (1)

RAMMS+EIN (578166) | more than 4 years ago | (#33351754)

``Since their introduction in 1971, leap seconds have proved problematic for at least a few software programs. The leap second added on to the end of 2008, for instance, caused Oracle cluster software to reboot unexpectedly in some cases.''

That just means that the software contains invalid assumptions. And, in this case, it seems to me that it was quite poorly worked out. Time being off by a second causes the system to reboot? I don't think that's what the customers ordered.

FUCKING NIGGERS!!! (-1, Troll)

Anonymous Coward | more than 4 years ago | (#33351774)

I'm so damned sick of the fucking GNAA!!!

Superior solution (1)

butlerm (3112) | more than 4 years ago | (#33351790)

Getting rid of leap seconds in the representation would be a mistake in the long run. A much superior fix would be to have computers keep track of TAI internally and then convert to UTC with a leap second table, much the same way we convert to local time with a time zone table.

Cluster software should be running off of a leap second free distributed clock, and TAI or the equivalent is the best one we have, handily provided (within a constant) on a world wide basis courtesy of the GPS system.

POSIX time_t values as it stands today isn't much of a clock at all, more like a short hand for encoding a wall time. We should have a new interface for a reference clock that doesn't need unpredictable adjustments every couple of years, _by definition_.

Re:Superior solution (1)

arcade (16638) | more than 4 years ago | (#33351966)

Indeed. I've been arguing for using TAI as the basis for unix time for a while, then have various time-functions return UTC.

One could have an /etc/leapseconds that is kept up to date by ntp, which gets its leapseconds from it's upstream ntp-servers. It could simply list the seconds-from-epoch where a leap should be inserted. In other words, it would slowly be appended to whenver a new leapsecond is announced.

Libraries read /etc/leapseconds to figure out how to convert TAI to whatever timezone the user wants.

What about leap days? (0)

Anonymous Coward | more than 4 years ago | (#33351802)

I doubt most of us would miss Mondays.

Please do this ten years ago! (1)

TimToady (52230) | more than 4 years ago | (#33351852)

They ought to have abandoned leap seconds in the year 2000, which would have made a dandy new epoch, and simplified all date calculations for a millennium or so. There is absolutely no reason to inflict leap seconds on civil time; the amount I'm off from the center of my current time zone already introduces more error than that. It's just not important to anyone but astronomers or masochists. Well, and maybe sadists (especially standards wonks).

Representative sample of tech reporting (1)

c0lo (1497653) | more than 4 years ago | (#33352002)

From TFA:

Since 1971, 24 leap seconds have been added on to UTC in order to reconcile UTC and Universal Time.

In the revised ITU plan, the divergence between UTC and UT will be allowed to grow over the next few hundred years, and could be reconciled by a single leap hour at some point.

Hmmm... let's say: 40 years for 24 leap seconds... yeah... it would be allowed to grow over the next 60 hundreds years... quite a few indeed (some would even argue that's the age of the world).

Re:Representative sample of tech reporting (1)

at10u8 (179705) | more than 4 years ago | (#33352050)

the deviation is quadratic [ucolick.org] , so an hour accumulates 800 to 900 years [ucolick.org]

oracle? (1)

omidaladini (940882) | more than 4 years ago | (#33352016)

Can someone explain what kind of business the Oracle cluster was doing with the seconds?!
Load More Comments
Slashdot Login

Need an Account?

Forgot your password?