'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."
The problem with leap seconds... (Score:5, Informative)
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:Poor solution (Score:2, Informative)
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:Oracle sholuld simply fix their software... (Score:5, Informative)
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:Stupid (Score:5, Informative)
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.
the problem will not go away even without leaps (Score:4, Informative)
Re:Stupid (Score:4, Informative)
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:Poor solution (Score:2, Informative)
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 (Score:4, Informative)
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
...except that days aren't a constant length (Score:3, Informative)
Every day is a slightly different length due to tides, etc. Even strong winds can shave off (or add) a microsecond or two.
The BBC did a documentary on it [bbc.co.uk].
Re:Poor solution (Score:4, Informative)
1 BC was followed by 1 AD.
Not with ISO 8601 [wikipedia.org] time representation, which is more logical having a year zero before year one.
Re:Oracle sholuld simply fix their software... (Score:3, Informative)
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.
The answer can be found in the Wikipedia [wikipedia.org] article on leap seconds - the need for leap seconds isn't constant and predictable.
You people ... (Score:4, Informative)
There's a reason why the second is defined based on an atomic phenomenon. An earth day is something hilariously unreliable; it varies all the time. A near earth asteroid would measurably alter it. Today we can measure time with accuracies in the 10^-15 or something, possibly even less. And besides, you're confusing the problem of defining the base unit (second) with choosing its scale and keeping a calendar. The SI second was scaled to look like the standard second used for centuries, just defined more precisely. The problem here is that the "real" second in the historical definition (one nth of a day) varies because of astronomical phenomenons that cannot be predicted (unless you can solve the n body problem for n very large and have inventoried the whole solar system), it's not a time keeping problem.
There's a solution to all this, it's called TAI. There is no reason not to use it but ignorance and incompetence. Every other "solution" that has been advanced here was completely, utterly stupid.
Re:Oracle sholuld simply fix their software... (Score:4, Informative)
Re:Poor solution (Score:4, Informative)
I think it was called 753 AUC
According to Wikipedia [wikipedia.org], it tended only to be called that by later historians:
Renaissance editors sometimes added AUC to Roman manuscripts they published, giving the false impression that the Romans usually numbered their years using the AUC system. In fact, modern historians use AUC much more frequently than the Romans themselves did. The dominant method of identifying Roman years in Roman times was to name the two consuls who held office that year. The regnal year of the emperor was also used to identify years, especially in the Byzantine Empire after 537 when Justinian required its use.
Re:Oracle sholuld simply fix their software... (Score:1, Informative)
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.
Because in the intervening two weeks you now have inaccurate time as you slew/step the clock. You're gaining accuracy at 23:59:59, but losing it in tiny chucks up to that point.
To a certain extent it's zero sum.
Re:Let's see if I've got this right (Score:1, Informative)
That's nothing. Read this (The OOXML leap year bug and the Chernobyl design pattern [robweir.com]) and weep...
Re:Let's see if I've got this right (Score:3, Informative)
Re:Let's see if I've got this right (Score:1, Informative)
Daylight Savings has had numerous studies showing reduced electricity consumption.
Newer Daylight Savings studies often find either no appreciable reduction or even an increase.
Re:Poor solution (Score:2, Informative)
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).
No, GMT=UT1 is an astronomical timescale, based on astronomical observations.
UTC is based on TAI and it is ajusted with leap seconds to track UT1 with an error less than 0.9 seconds.
Here [wikipedia.org].
Re:Stupid (Score:3, Informative)
That timescale already exists. It is called TIA. It is identical to UTC except for having no leap seconds, and an initial deviation of exactly 10 seconds. The second ticks occur at exactly the same time as UTC. It is always an exact number of seconds off from UTC, that delta increases or decreases as leap seconds are inserted in UTC. It is currently offset by exactly 34 seconds.
We need constant seconds (Score:3, Informative)
The problem is that it would introduce variable seconds, which would cause much worse problems.
One example is electric power systems. The frequency in the AC power system is what determines how much power should be generated, if the frequency is above or below 60 Hz (or 50 Hz) then each power station should decrease or increase their generation by some amount proportional to the frequency difference.
The accumulated difference in total cycles over a period is used to calculate what was the difference between total energy needed and generated on that period. With leap seconds all you need to do is to divide total cycles by total seconds to get average frequency. With slow adjustment this would be much more difficult.
Re:Let's see if I've got this right (Score:2, Informative)
Re:Let's see if I've got this right (Score:3, Informative)
Re:Oracle sholuld simply fix their software... (Score:3, Informative)
Oracle is irrelevant.
They would be simpler. The TAI second is the standard second, used by both TAI and UTC. Timekeeping consists of numbering seconds as they pass. TAI simply numbers them sequentially. UTC also numbers them (using a rather odd number system) but jiggers the numbers every few years to adjust for the erratic rotation of the Earth and then pretends nothing has happened. The proposal is to instead number the seconds sequentially and distribute a lookup table containing corrections for the Earth's rotation. This what the GPS already does.
Re:Let's see if I've got this right (Score:4, Informative)
On the other hand, modern studies such as:
http://energy.ca.gov/2007publications/CEC-200-2007-004/CEC-200-2007-004.PDF [ca.gov]
and
http://online.wsj.com/public/article/SB120406767043794825.html [wsj.com]
(don't have a link to the article they published, sorry)
These imply that the savings are negligible or, in the case of Indiana, *increased* electric usage. There is no clear answer, since the results depend heavily on the breakdown of electric usage (A/C, eletronics, etc), which varies depending on your region.
Re:Let's see if I've got this right (Score:5, Informative)
If you can't answer "When will each of the next 10 leap seconds be?" and "When were the last 10 leap seconds?" then you are pretty much fucked from a programming standpoint of 'handling' it in any sane manner using common time encodings, which use a count of intervals (usually seconds, or milliseconds) since some specific date and time.
Leap seconds make it impossible to incorporate them into intervals because leap seconds are not computationally predictable.
They are simply arbitrary announcements from the time keepers "we are adjusting the clocks by 1 second on such and such a date. We dont know when we will adjust them again.. we'll keep you posted."
Leap seconds are not like leap years, which are easily handled because they are introduced systematically based on only the interval value.
Re:Let's see if I've got this right (Score:3, Informative)
It sounds like the problem is due to the fact that the leap second is implemented as a step function and not a slew.
It is because the step function is non-systematic. Leap years are implemented as step functions just fine. You simply cannot write an algorithm to predict when a leap second will be introduced based only on the time, which is the problem.
Leap seconds are ad hoc seat-of-the-pants alterations to the time. They violate the monotonically steadily increasing property of time encoding, so simply cannot be tolerated in any system that benefits from having monotonically steadily increasing time values.
Re:Stupid (Score:3, Informative)
but these are all standards. Different standards for different purposes. And UTC was chosen for civil timekeeping,as this is the standard that aims to keep in sync with the actual astronomical time.
besides that.. if you took out the leap seconds,you would get TIA! You'd have two identical standards with different names, and none of them would fulfill the requirement for civil timekeeping. (no noon drifting off into the evenings)
It's definitely no hassle! (Score:2, Informative)
Oh, it's definitely no hassle as long as the correct measures are taken.
First, you need to make sure that you standardize the summer and winter hours across the whole nation, so that everybody switches over on the same date. It would be very confusing to have to call every business you deal with in order to ask whether they've already switched over to winter time.
Second, you should probably amend all local laws that specify specific times of the day so that they specify different times for summer and winter. You know, if my neighborhood bar opens at 8pm in summer and 7pm in winter, I would be pissed if a law that forces bars to close at 2am went unamended. I'd get one fewer bar hour in summer, and that's clearly unacceptable.
Third, in addition to amending all the laws, you have to make sure that you redo all the street signs that mention specific hours, so that that "free parking after 6pm" sign now lists separate summer and winter hours.
Fourth, whenever you schedule a late or early appointment in your calendar at a significant time ahead, make sure you take care to check whether the day you're scheduling it for is not past the switchover date, and you accidentally schedule the appointment for a non-laborable time for that season. Hey, we should probably redesign paper agendas so that the lines showing the working hours change for the seasons.
So you see, yes, it's definitely no hassle at all, as long as you take all of these measures, and any other ones that I may have forgotten.
Re:Let's see if I've got this right (Score:2, Informative)
If you can't answer "When will each of the next 10 leap seconds be?" and "When were the last 10 leap seconds?" then you are pretty much fucked from a programming standpoint of 'handling' it in any sane manner using common time encodings, which use a count of intervals (usually seconds, or milliseconds) since some specific date and time.
ftp://time.nist.gov/pub/leap-seconds.list [nist.gov] is a publicly available file that lists all announced leap seconds (past and future), designed for use in time conversion functions. And yes, it does need to be periodically refreshed, just like the zoneinfo database.
Life would be much easier if all manufacturers adjusted for leap seconds in their localtime() and gmtime() functions, rather than in the hardware clocks and their time() functions.
Re:Let's see if I've got this right (Score:1, Informative)
Tell that to the Air Force. They had a six F-22 Raptors crash multiple computer systems as they passed over the International Date Line. They were unable to reboot the systems in flight. Fortunately it was only minor systems like fuel subsystems, navigation and some communications systems that crashed. They were flying with some tankers that were able to "guide dog" them to Hawaii.