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