SoylentNews is people
SoylentNews
from the like-this-year-hasn't-been-long-enough dept.
Phys.org (among many other sites) is reporting on a leap second being added before the end of 2016:
As if 2016 has not been long enough, the year's dying minute will last an extra second to make up for time lost to Earth's slowing rotation, timekeepers say.
Countries that use Coordinated Universal Time—several West African nations, Britain, Ireland and Iceland—will add the leap second during the midnight countdown to 2017—making the year's final minute 61 seconds long.
For others, the timing will be determined by the time zone they live in, relative to UTC.
"This extra second, or leap second, makes it possible to align astronomical time, which is irregular and determined by Earth's rotation, with UTC which is extremely stable and has been determined by atomic clocks since 1967," the Paris Observatory said in a statement.
The observatory houses the International Earth Rotation and Reference Systems Service (IERS), responsible for synchronising time.
"The sequence of dates of the UTC second markers will be: 2016 December 31 23h 59m 59s, 2016 December 31 23h 59m 60s, 2017 January 1, 0h 0m 0s," the IERS website states.
Here is the original IERS announcement. There have been times in the past when the addition of a leap-second caused havoc — it is non-trivial to update the clocks on all the systems in an organization at the same time. When activity "A" happens before activity "B", but because of inconsistent system clocks the timestamps imply otherwise, things can go sideways in a hurry.
(Score: 0) by Anonymous Coward on Friday December 30 2016, @05:37PM
Give all computers a break for 1 second out of the year. Outside of cruise missiles, landing planes, and autonomous cars there are not a whole lost of devices that care about the time+date that it should affect, and most that it COULD should be handled by a time protocol or adjustment during standard maintenance times, of which any serious industrial equipment will have at least one per year.
(Score: 4, Informative) by martyb on Friday December 30 2016, @06:23PM
It seems easy, but the reality is far more complicated. For some background, please read Wikipedia's entry on the Leap Second [wikipedia.org]. Pay special attention to the section examples of problems associated with the leap second [wikipedia.org]. If it really were that easy, I'd suspect that some of the people who are actually responsible for the calculation and distribution of notices about leap seconds would have found that easier way by now.
There have been proposals to abolish the leap second [wikipedia.org] and none have been ratified because of issues with it.
The best proposals I have seen are analogous to how *nix systems have the system clock set to UTC and then compute/display time based on an offset from that. Wikipedia concisely states this as follows:
This is not without its own problems, as there is the question of what do you do with all of the existing devices that are already out in the field.
See, also, the section Workarounds for leap second problems [wikipedia.org] for some other ideas and complications.
Wit is intellect, dancing.
(Score: 2) by JoeMerchant on Friday December 30 2016, @06:48PM
So, it seems that we always are adding seconds - shouldn't we just recalibrate time so that we don't need to add or take away seconds for a long-ish period? If we can predict where the earth's rotation is going for the next 100 years, we could calibrate time to run a little ahead astronomically for a few years, then fall back, rinse, lather, repeat.
Think of all the fun that process engineers and others will have with a variable second that changes by 0.00001% every 10 years. Other than GPS clocks and similar truly time-critical devices, the change would be deep inside the normal process variations.
🌻🌻 [google.com]
(Score: 2) by martyb on Friday December 30 2016, @07:06PM
Again, seems simple, doesn't it?
Look again at the Wikipedia article on the leap second [wikipedia.org], paying special attention to the section Slowing rotation of the Earth [wikipedia.org]:
Though you are correct in asserting that leap seconds have only been added so far, there is no requirement for that and the current system has provisions for the removal of a "leap" second. In actuality, the overall trend has been for the length of an Earth day to shorten! [wikipedia.org]
It's quite the rabbit hole, isn't it?
Wit is intellect, dancing.
(Score: 2) by JoeMerchant on Friday December 30 2016, @11:32PM
I've seen a couple of things about the rotation rate of the Earth through history - human evolution was supposed to have happened mostly on a longer 25ish hour day, but then in deep history the Earth's rotation was supposed to have been much faster.
I'm wondering if there's a net correlation between global temperature and rotational period - more heat, oceans expand, should be like the skater letting arms out in a spin to slow down - but then the glaciers melt and slide off their mountains into the ocean... probably a smaller effect than the expansion of the oceans, but a counterbalance of sorts. Put all of this against a backdrop of tidal friction, etc. I'm sure "scientists" and especially mathematicians can find all sorts of correlations (but, never prove causation...)
🌻🌻 [google.com]
(Score: 2) by AthanasiusKircher on Saturday December 31 2016, @01:10AM
human evolution was supposed to have happened mostly on a longer 25ish hour day
Huh? Based on what? Citation?
(The only thing I could possibly think was connected to such a claim is the supposed sleep-cycle period in humans which years ago was measured to be slightly greater than 24 hours. But those earlier estimates as high as 25 or 26 hours have been revised with more recent research [harvard.edu], so the average circadian clock rhythm is now thought to be only a few minutes longer than 24 hours... and even that isn't exactly proof of a longer rotational period, since days are often a few minutes longer or shorter than the previous ones with seasonal variations.)
(Score: 2) by JoeMerchant on Saturday December 31 2016, @04:32AM
It may have been the sleep-cycle research. I'm remembering something from 25+ years ago, and lots of stuff from back then has been formally retracted, debunked, etc...
🌻🌻 [google.com]
(Score: 2) by AthanasiusKircher on Saturday December 31 2016, @01:02AM
It's quite the rabbit hole, isn't it?
It is indeed, but I personally can't understand why we feel the need to keep UTC aligned within 1 second to noon at solar zenith. The introduction of time zones already means most places happily live with a deviation of +/- ~30 minutes from that (and in many places more). DST introduces an additional hour offset that most people tend to complain about twice/year but otherwise never notice.
Maybe once the error accumulates to 10 minutes or more in a few centuries, we can deal with a correction. But for now, people who need that 1-second precision (e.g., astronomers) already have UT1 [wikipedia.org] instead of UTC -- and for the professionals these days UTC isn't precise enough. And for those systems which don't need or want the corrections, they have TAI [wikipedia.org] and GPS time [wikipedia.org].
We already have alternative time standards for EVERYONE who needs actual precision. UTC is just the average time standard for the common people. Who cares if it falls a few seconds or even several minutes away from aligning with solar zenith?
(Score: 2) by requerdanos on Saturday December 31 2016, @01:50AM
Let me get this straight. You are proposing replacing the inconvenient leap second with the supposedly more workable ten leap minutes?
Mmm hmm.
(Score: 2) by AthanasiusKircher on Saturday December 31 2016, @06:43AM
You are proposing replacing the inconvenient leap second with the supposedly more workable ten leap minutes?
Actually, no. What I'm proposing is that we postpone this problem so far into the future that it's very unlikely anyone will give a darn about "mean solar time" by that point as a "universal" time standard. A few centuries in the future, we'll either all be run by AIs, have folks living on other planets so the idea of UTC would be rather meaningless, or whatever. Also, most people will likely adjust their schedules to the gradual drift of clocks over time, so nobody would even care to "correct" that 10 minutes, just as most people don't care about the DST shift a week or two after it happens.
Even if we wanted for some bizarre reason to "fix" that problem in that far future -- by the time this ACTUALLY becomes a problem that the clocks are far enough off that anyone would give a damn, the earth's rotation will likely have slowed to the point that adding leap seconds is going to become a regular occurrence, so the current UTC system will ALREADY seem like an unworkable permanent solution. (It already IS an unworkable solution for the true long-term -- thousands of years -- due to the fact that we KNOW the earth's rotation will slow down, and at some point we WILL need more than an extra second per month.) Adding in 10 minutes or whatever by that point will be the LEAST of our problems.
Also, we already have a time standard that tracks astronomical noon. It's called UT1. (Technically, the definition is a little more complicated than that, but there it is.) UTC is meant to be a pragmatic time standard that's precise enough for common, everyday people to use. Common everyday people don't care whether their clocks are off from solar zenith at Greenwich or whatever by a few seconds or a few minutes. Tinkering with the timeline on a variable basis every month (right now it has only happened in June or December, but theoretically could happen in other months) is a huge issue that will itself become obsolete too. Whether we continue the UTC plan for the next few centuries or not, we'll still have to face choices about changing implementation eventually.
In the meantime, perhaps we can just dispense with a pain-in-the-ass half solution that is only convenient for observatories and very inconvenient for just about everyone else who designs a computer system which might be sensitive to arbitrary introduction of extra seconds. (Or removal of! Let's not forget that the current UTC standard allows skipping a second too! We haven't had the need yet, but given the variability in earth's speed, it could happen. How many systems will break when that wacko scenario happens, because nobody read the detailed timespecs and realized they might need to DELETE a second!)
And maybe enough astronomers do benefit from having something that isn't quite as precise as UT1 but is as arbitrarily variable (but not more than a second) like UTC. That's great. Let them have their own time standard too. But why again are we ALL coupling our clocks to THAT standard for the 99.99% of computers and other systems that don't care when solar zenith occurs at Greenwich??
(Score: 0) by Anonymous Coward on Saturday December 31 2016, @08:34PM
Leap seconds are a non problem for average people who do not operate to the precision of one second nor to the accuracy of one second per year. Only computers care and we have hacks to handle that situation. The first rule before taking action should be: don't make the situation worse!
Anyone who truly cares about precision timekeeping already has a proper solution; the others don't care enough for a new system system em implemented.
(Score: 2) by sjames on Friday December 30 2016, @08:34PM
The vast majority of systems really don't care that much. That's why the news isn't flooded with reports of people stuck in elevators or losing power of having their DVRs freak out every leap second.
Other cases REALLY do care, but even most of them will be OK if they are set to the same master clock.
One problem is that the 'official' handling of a leap second ins't even something most computers are equipped to do (nor analog clocks for that matter). Officially, a leap second is handled by having the clock count (in UTC) 23:59:59 -> 23:59:60 -> 00:00:00. But practically no computers can even express 23:59:60 as anything but a denormalized alias for 00:00:00 since they keep time internally as the number of seconds since the epoch. Same for an analog clock.
More feasible (but not quite per standard) would be to subtract one second from the system clock just as it would otherwise tick over to 00:00:00. This is what the official NTP servers do. It's at least within the design of the system to be able to express that, but it can still be a big problem if you want to know how many times an event happened in the second of 23:59:59 compared to 23:59:58 since the former would effectively last 2 seconds, making it look like a huge spike in the rate.
In practice for most systems that care enough to synchronize with NTP, they simply run as usual and suddenly at 00:00:00 they find themselves 1 second ahead and slow the tick of their clock slightly so that they fall back in sync with NTP over the next few minutes (known as slewing the clock). In most cases, as long as the slew rate is the same throughout the consistent time domain and everybody syncs to the same clock, this is the right thing even if it is far from the official standard. It introduces a small and generally tolerable error for a few minutes. A number of unofficial tier 2 and above (in NTP, higher tiers are further removed from the atomic clock) do more of less this themselves.
Google deliberately slews the second starting hours before the leap second and ending hours after. IMHO, it's a lot of effort for a small gain, but as long as everyone in a consistent time domain uses the google servers, it's fine though some object to creating yet another time standard.
As you point out, for equipment that can have a downtime for maintenance and care more about consistent time than absolute correctness such as aircraft navigation, just do it during the next scheduled maintenance.
Just to add to the confusion, a consistent time domain is only consistent to within a margin of error.
(Score: 2) by krishnoid on Friday December 30 2016, @10:11PM
Google deliberately slews the second starting hours before the leap second and ending hours after.
Silly question -- contextually, it doesn't seem like the dictionary definition of 'slew' describes this sort of adjustment. Has this definition changed ('slewed' :-) somewhat, and can someone provide a reference for it here?
(Score: 3, Informative) by sjames on Saturday December 31 2016, @12:10AM
For bnetter or worse, it's the word chosen for use in various documents on clock handling in a computer. It is used as opposed to stepping where the clock is simply set to the corrected time instantly. Slewing also guarantees monotonic time (it never goes backwards).
Google "ntp clock slew" for a bazillion references.