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 darkfeline on Friday December 30 2016, @08:45PM
>If precision down to the second at all times is required, you don't use UTC.
UTC is precise. What isn't precise is UNIX time; note the difference. Every single moment in time corresponds to a single point in UTC. UNIX time is defined in terms of UTC, IGNORING LEAP SECONDS. The problem here is that UNIX time will skip, but UTC won't.
If we wanted to solve this problem, we would make UNIX time v2, which could be based off of TAI, or UTC including leap seconds. I'm not sure the transition costs would be worth it though.
> If you notice, many times legal documents will specify that a policy or contract will begin at some date at 12:01 AM
to eliminate the ambiguity of when a new day begins: at midnight, or the second after? (For the record, the widely accepted answer is one second after 12:59:59 PM, i.e., the day starts at midnight.)
That's only a problem because normal people use one-based indexing, which is not mathematically sound for continuous scales (you end up with a "hole"), whereas zero-based indexing is mathematically sound.
Note the distinction between discrete scales, which would be used when counting, and continuous scales, which is a superset of discrete scales.
Join the SDF Public Access UNIX System today!
(Score: 0) by Anonymous Coward on Saturday December 31 2016, @02:08AM
You are confused.
Unix time is defined as seconds elapsed since Jan 1, 1970 without including any leap seconds. We agree on that. That doesn't make Unix time any less precise than UTC. All UTC does with its leap seconds is to make the calendar year longer; specifically, it makes the month (even more specifically, the particular minute within the month containing the leap second) one second longer than usual, i.e., instead of that particular minute containing 60 seconds, it contains 61 seconds. That's all. There are no "gaps" in Unix time just as there are no "gaps" in TAI or GPS time. Unix time is just a running count of seconds elapsed from a starting point just like TAI or GPS. One can convert UTC -to- (Unix time, TAI, or GPS) with zero loss of precision -or- the reverse just by applying a historical table of when leap seconds were applied.
(Score: 0) by Anonymous Coward on Saturday December 31 2016, @04:54AM
The way Unix time kludges in "support" for leap seconds (it doesn't support them, it employs hacks to sync back up with UTC) is pretty ugly and is explained in detail here:
https://en.m.wikipedia.org/wiki/Unix_time [wikipedia.org]
(Score: 2) by maxwell demon on Saturday December 31 2016, @12:23PM
The whole point of the original definition (seconds since a certain point in time) was perfect. The leap seconds could (and should) have been considered during conversion from/to local time, just as the time zone is. As bonus, you'd get correct handling of the leap second automatically as soon as the relevant tzdata is installed, even if at the time of the leap second no external time source is available.
The Tao of math: The numbers you can count are not the real numbers.
(Score: 0) by Anonymous Coward on Saturday December 31 2016, @04:16PM
I agree completely. That would be the obvious, straightforward, and unambiguous way to solve it, i.e., the correct way.
Therefore, that way never stood a chance. Computer nerds LOVE the complicated, undependable hack more than anything else. Why fix it when you can kludge it instead? I think it's because the people who came up with the hack thought backward compatibility with crappy time libraries would make times be off by some seconds potentially, but their leap second "hack" pretty much GUARANTEES that will be the case forever going forward. It takes a very clever mind to come up with a solution this stupid.