'Leap Seconds' May Be Eliminated From UTC 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."
Oracle sholuld simply fix their software... (Score:3, Insightful)
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?
Poor solution (Score:5, Insightful)
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 (Score:2, Insightful)
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.
Changing time because of Oracle? (Score:4, Insightful)
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.
Ok... (Score:5, Insightful)
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?
Re:Poor solution (Score:5, Insightful)
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 (Score:1, Insightful)
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.
Let's see if I've got this right (Score:5, Insightful)
We have to make every clock in the world inaccurate because Oracle's software is crap...?
Re:Poor solution (Score:3, Insightful)
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.
OK, now hands up why the wonderful leap-day system hasn't needed adjustment since 1752? ... "mumble mumble leap seconds mumble mumble?"
Anyone?
Yes, you at the back
Speak up lad!
"Sorry Sir - is it because the sensible use of regular leap seconds means a leap day is only required once every for years and they are actually both part of the same time adjustment because a leap day is actually made up of many leap seconds?"
Yes indeed, well done. Yes the time adjustment required to keep our calendar in sync with the passage of the Earth around the Sun requires somewhere around a 1/4 day extra per year, give or take a second or two, and it was decided at some point [wikipedia.org] that an extra day every 4 years would be a sensible way to make the majority of the correction leaving the odd seconds to be added as required to remove the need to add extra leap days far less often.
Re:Stupid (Score:5, Insightful)
Why abolish it?
You're free to CHOOSE your timescale! GPS, UTC, UT1, TIA.....
So if leap seconds confuse you, use a timescale without them. Thats what they're for. But keep the timescale that's supposed to be in sync with earth rotation in sync with earth rotation!
Re:Ok... (Score:2, Insightful)
The correct value of pi is the conclusion of a theorem. If you propose that the ratio of the circumference to the diameter is exactly 3.14, we can use math to prove that you're wrong. We don't have any choice as to what the value is; if you assume the wrong value for pi and try to reason from that assumption, you're going to end up with contradictory conclusions.
UTC, on the other hand, is an arbitrary convention. Its inventors and adopters chose to keep it within one second of GMT by adding or subtracting leap seconds at the unpredictable times when it starts to diverge too much. They could have chosen not to care about it, and they could now choose to stop doing so. All that we're changing is the labels in the scale in the time axis.
To give an analogy, it's like deciding to write pi in binary from now forward instead of decimal: 11.001001000011111101101010100010001... It's the same number, but we've labeled it differently.
That's not a solution (Score:4, Insightful)
Clocks should strive to give the most accurate measurement, not lie to their users.
The solution exists, it's TAI. You use TAI internally and convert to UTC (or your TZ) when displaying, similar to unix time.
Re:The real problem is using seconds for everythin (Score:3, Insightful)
This is one of many, many attempts to make the problem seem to go away, unfortunately enough their choice of 1000 seconds for the smoothing period is close to the worst possible: 1 second in 1000 is 1000 parts per million or 1000 ppm.
NTP has a maximum slewing rate of 500 ppm or half a second every 1000 seconds, so if your NTP upstream server was to start such an adjustment period, every single connected client would drop out of sync and be forced to do several steps each time the offset got above 128 ms. :-(
To make this work every single computer clock would need to be updated, while all the national radio standards, like the German 77,5 MHz transmitter, would have to disregard the new standard because the radio receivers would be unable to track it when it started the adjustment period.
Terje
Re:That's not a solution (Score:3, Insightful)
The most accurate measurement of what though? elapsed time or time of day?
It's trivial to derive time of day from an accurate absolute clock. It's about as hard as displaying a calendar, i.e. not that hard.
On the other hand it's impossible to derive an accurate clock from an inaccurate calendar clock.
The big problem is that leap seconds aren't predictable so it's not possible to convert accurately between TAI and UTC for a time in the future nor is it possible for a system that isn't receiving updates to the conversion table to covert accurately for past/current time.
It's about as difficult as fetching a file over the internet, i.e. trivial. And if you can't fetch that damn file, the only thing you risk is at most a couple second offset when /displaying/. Your calculations are going to be fine; and missing one second on an interval is a big deal (esp. if you're measuring intervals on the order of 1s), while having an offset on a /date/ is hardly ever an issue. And anyway, as soon as you get back to civilization, and assuming you stored your dates in TAI, you can see them accurately in UTC retroactively.
It follows that if a time is repeatedly converted between TAI and UTC by systems in different states of updating (as could easilly happen in a situation where a gradual migration from UTC to TAI is in progress) there could be some rather nasty error buildups. Much the same problem applies with DST but at least most developed countries tend to keep thier DST rules pretty consistent
That doesn't strike me as a very common situation. Calculating time intervals, on the other hand, is a very common task. See time(1).
Re:Let's see if I've got this right (Score:4, Insightful)
Re:Let's see if I've got this right (Score:5, Insightful)
Daylight Savings has had numerous studies showing reduced electricity consumption.
Yes, the question is more if there's more or less hassle to have summer and winter opening hours than to change "time" itself.
Mod parent up. (Score:3, Insightful)
The solution, as the parent says, is to continue publishing leap second announcements but to start distributing TAI. Those who feel a need to track UTC can then insert the leap seconds themselves while other can track TAI and provide lookup tables for conversion to UTC or local time for display just as we do now for DST an local time zones.
And no, this does not mean putting the correction off for some future generation to deal with. It means realizing that there is no need for a correction at all and that Earth rotation based time is merely a local convention to be handled by an appropriate lookup table.
Re:Let's see if I've got this right (Score:5, Insightful)
Never mind leap seconds, end DST (Score:3, Insightful)
why don't they drop the silly daylight saving time thing.
Its been proved that nowdays it doesn't save any electricity, and just messes up peoples schedules and biological clocks.
In the latest issue of SciAm its listed and one of the inventions humanity would be better off without. (along with the space shuttle)
Re:Let's see if I've got this right (Score:3, Insightful)
see air traffic control problems for a good reason why we shouldn't have them - safety-critical systems that depend on time synchronisation and don't reliably work with leap seconds. Great
The same argument can be made for leap-days.
December 31 23:59:60 is no less valid than February 29. Throwing out accurate timekeeping because some software designers didn't do their homework is not a good solution. Throw out the bad designers instead...or at least keep them away from "safety-critical systems"
Re:Oracle sholuld simply fix their software... (Score:3, Insightful)
The answer can be found in the Wikipedia article on leap seconds - the need for leap seconds isn't constant and predictable.
That doesn't really address his question, though. His proposition is a different way to implement leap seconds, not a way to determine if they're needed. I don't like his idea either, but for different reasons.
Re:Let's see if I've got this right (Score:4, Insightful)
Wrong. They exist because the solar day is getting longer every time. The tides caused by the moon are slowing down the earth's rotation rate.
They should. If a programmer is so incompetent he can't get leap seconds right, I shudder to think what else he did wrong.
Re:Let's see if I've got this right (Score:5, Insightful)
No it can't, for three reasons. Firstly, leap days are deterministic. They happen based on a set of simple rules. If the year is divisible by 4, you get a leap year, unless the year is divisible by 100 but not by 400. Leap seconds, in contrast depend on a variable that changes daily, so are not predictable. They are fudged in with a few months notice, requiring every computer that needs to deal with them to be updated regularly.
Secondly, leap years don't violate basic sanity checking rules. You can assert that every month is 28-31 days, and that's not broken by leap years. You can assert that every minute contains 60 seconds. In the last decade, that has been true for 2,106,718 minutes, and false for 2. In every year before 1970, it was true.
Finally, leap years solve a real problem. The point of a solar calendar is that the seasons are in the same place every years. Having the seasons move made it difficult for people to plan when to plant crops. It's less important now, but having the seasons move around would be noticeable for everyone and irritating for a lot of people. In contrast, the only 'problem' that leap seconds solve is that the sun is not at its highest above the meridian at precisely 12:00. As the poster above you pointed out, the skew from not having leap seconds for a thousand years makes less of a difference to the position of the sun than simply not living quite on the meridian.
Leap seconds are a (very) complex solution looking for a problem.
Re:Let's see if I've got this right (Score:3, Insightful)
If we're still going to "get up when it's light, go to bed when it's dark", it doesn't exactly sound like "we don't rely on the sun anymore".
The knowledge that it's 11:00 doesn't tell me anything about whether it's a reasonable time to call someone in another part of the world, for example. Instead of checking a time zone offset I'd have to consult local sunrise/sunset times?
Then there's daylight saving time -- it's easier to adjust the clocks than to adjust every schedule. I guess you'd ditch that too?
Would midnight and noon still be 0:00 and 12:00, or could you have mid"night" in the middle of the day? :-P