Slashdot Mirror
Extra Leap Second To Be Added To Clocks On June 30
hcs_$reboot writes: On June 30 this year, the day will last a tad longer — one second longer, to be precise — as a leap second is to be added to clocks worldwide. The time UTC will go from 23:59:59 to 23:59:60 in order to cope with Earth's rotation slowing down a bit. So, what do you intend to do during that extra second added to that day? Well, you may want to fix your systems. The last time a leap second was added, in 2012, a number of websites, Java and even Linux experienced some troubles. Leap seconds can be disruptive to precision systems used for navigation and communication. Is there a better way of dealing with the need for leap seconds?
There is a better way. Just wait several thousand years and then add one leap hour.
Of course, there's a better way. Just ignore the small error until it adds up to an hour, and then skip a DST transition.
"Is there a better way of dealing with the need for leap seconds?"
Sure, use/write software which correctly handles time. Leap seconds with their current, well defined behavior, have been around for over 40 years.
If you have software which assumes a minute is always 60 seconds, an hour is always 60, 60 second minutes, etc., you're doing it wrong.
"National Security is the chief cause of national insecurity." - Celine's First Law
There are two domains to consider.... human and computer. Humans won't notice or care about sunrise being off by one second or even much more than that. Computers need exact consistency. So the solution is, as stated, to update the clocks to the actual rotation only infrequently. Everyone, man and machine, will be happy.
"He took a duck in the face at 250 knots." -- William Gibson, Pattern Recognition
A recent draft of the set of options which will be presented when the World Radio Conference votes this fall is visible at http://acma.gov.au/Industry/Sp... This draft has options A, B, and C, but it is likely to be wordsmithed a lot before it is finished.
The problem is that you don't understand it.
First, you've got all those new solar panels absorbing photons from the sun, but only in one direction, and then you've got all of those wind farms and tidal hydro plants adding friction to things. Of course the earth is being slowed down. Every time some do-gooder plants a tree, what do you think happens? More friction. Friction slows down the planet and causes heat. Check it for yourself - try walking briskly to the fridge and back, and then try shuffling your feet on the carpet as you do the same. Heat! Slowing down! Exactly like what happens when the atmosphere has to slide over something that's in the way, like a rainforest. No matter how many coal-bearing mountains we smooth out to help with this problem, the infestation of "tiny houses" clustered around hipster-friendly towns just slows the air back down again.
Don't disappoint your bird dog. Go to the range.
All we need to do is have everyone in the world face west and run.
No, the Earth really is slowing down very, very gradually. The tidal forces from the moon is slowly leeching off rotational energy from the Earch (as heat). See here: http://en.wikipedia.org/wiki/T...
If it's not network connected (ntp or gps), or connected to a properly calibrated atomic clock, it's going to be off by more than a second when the next leap second rolls around, anyway.
If you don't need time accurately sync'd to UTC, you can ignore leap seconds, so what's the problem? And if you do need time sync'd to UTC, you will need some regular external input which can include upcoming leap second info, so what's the problem?
"National Security is the chief cause of national insecurity." - Celine's First Law
...a better way of dealing with the need for leap seconds?"
Well... It could be worse. The last time we let the clocks go off we lost almost two weeks trying to fix it.
Let's just keep up with the leap seconds so that nobody has to cancel Christmas again.
The main problem is the wrong handling of UTC by NTP and Unix.
NTP is simply on the wrong time system. It is a system which is designed to accurately keep a monotonous steady time shared among millions of systems spread across time zones. It does not have any sensible way of dealing with the fact that some systems want to suddenly add a second or subtract one, just like it cannot deal with time zones or Mayan calendars. Those are simply outside its problem domain. Luckily the fix is simple: Stop handling leap seconds at all in NTP, just keep counting seconds. If you must handle it in NTP for those client systems too primitive to do it themselves, do it by transmitting the current offset between NTP time and UTC. The best solution would be to define NTP time to be TAI of course, but it will likely have to be TAI+offset to handle backwards compatibility.
Unix again does it wrong by keeping system time in UTC rather than TAI. UTC is useful for humans but difficult for machines, it should be handled by the human interface libraries, just like time zones. Kernel time should be TAI of course. When leap seconds are inserted, systems must be updated, but that is not particularly harder than keeping the time zone files up-to-date is already. Of course it would be a lot easier if the astronomers would let us know a few years in advance rather than six months, but then the offset between TAI and UTC could exceed 0.9 seconds, and as we all know that would bring Ragnarok.
GNU systems even have sets of time zones for precisely this reason: "POSIX" and "Right". Unfortunately it is not possible to use the "Right" time zones with current NTP.
Finally! A year of moderation! Ready for 2019?