Slashdot Mirror
Next Chapter In the Leap Second Story
at10u8 writes "The ITU-R and BIPM are holding a joint workshop on the Future of the International Time Scale. This is the next of many steps toward the possibility that radio broadcasts of time signals might abandon leap seconds. All of the presentations are online and the press release for the workshop indicates there will be video interviews afterwards."
The ITU has also put up an issue of ITU News with in depth articles.
I think they plan to speed up the Earth's rotation so that the computer clocks will stay synchronized with daylight.
Where are we going and why are we in a handbasket?
cant they just do these adjustments when we are scheduled to do the switch to or from daylight saving time since you have to fiddle with the clock anyway
So... err... how will it go now? Instead of posting a 60th second they will make the 59th second twice as long, and have everyone think their clocks are fast, accept that out of sync clocks are a fact of life, and just synchronize?
They'll simply stop trying to correct UTC to match the rotation angle of the earth. "Correcting" UTC that way is mostly helpful to astronomers, and for everyone else has no benefit and some significant drawbacks.
How can we continue to believe in a just universe and freedom to eat crackers if we have no ale?
Civil time has always been based on the sun. For anyone who doesn't like dealing with leap seconds, there are well established alternate timescales available which don't use them, such as GPS and TAI. There is no good reason to eliminate leap seconds from UTC, which was very specifically developed to closely track the earth's rotation, like its other UTx siblings. The people who want to eliminate leap seconds from UTC are the ones who chose their timescale poorly, and now want those who use it properly to suffer for their mistakes.
There's good coverage here.
"National Security is the chief cause of national insecurity." - Celine's First Law
missing link
"National Security is the chief cause of national insecurity." - Celine's First Law
This. If you don't want leap seconds and don't care if you're synchronized to the sun, you already have two timebases to choose from. Do this and you take away a use case from others, and then have THREE to choose from.
Leap seconds are problematic not because of sloppy coding but because they are a messy problem.
During the one second interval when they are applied, what happens to [UTC] timestamps on files that are modified? If you're compiling, an object file may be updated or not. Or, with rsync, a file may be transferred or not. Or, what about medical equipment [based on POSIX-compliant UTC (e.g. Linux, etc.)] that gives a patient an extra one second of radiation because the master clock is based on UTC?
Also, applications [which generally don't account for leap seconds] would get lurched, sometimes with disastrous results.
That's why Google came up with a "leap smear": http://www.theregister.co.uk/2011/09/19/google_has_to_lie_to_computers_about_time/
The solution we came up with came to be known as the 'leap smear'. We modified our internal Network Time Protocol [NTP] servers to gradually add a couple of milliseconds to every update, varying over a time window before the moment when the leap second actually happens. This meant that when it became time to add an extra second at midnight, our clocks had already taken this into account, by skewing the time over the course of the day. All of our servers were then able to continue as normal with the new year, blissfully unaware that a leap second had just occurred.
I confused nothing [re. leap days]. That was just a loose analogy. Nobody would notice if we applied leap seconds or not. Not even a leap minute every fifteen years would be noticed. And that's the maximum error you can have. Nobody will care if the sun sets in the west a minute earlier than you expect it to [based on TAI]. Better yet, since we tolerate daylight savings time, wait until the leap second error hits an hour. That will take 900 years minimum.
Since July 2012, IIRC, all corrections are now formally set at six month intervals. While most corrections have been in one direction, if we just kept track of the error, it might self correct over a long enough period.
Converting all systems (computers, cell phones, NTP, etc.) to use TAI internally would be a good thing. Convert to UTC when displaying the time [could be a user preference]. Everything becomes simpler and more accurate.
Those that truly need to track solar time are a minority (e.g. astronomers, etc.). Let them do the extra conversion rather than burdening the rest of the world [and the systems we use in our daily hitech/21st century lives].
Like a good neighbor, fsck is there
"During the one second interval when they are applied, what happens to [UTC] timestamps on files that are modified? If you're compiling, an object file may be updated or not. Or, with rsync, a file may be transferred or not."
Only with negative leapseconds, which have never been used ... as long as the timebase is monotonic these shouldn't fuck up. As for POSIX using a timebase which might not be always monotonic for file timestamps ... well that is sloppy coding. The sloppy coding being part of POSIX is no excuse.
"Or, what about medical equipment [based on POSIX-compliant UTC (e.g. Linux, etc.)] that gives a patient an extra one second of radiation because the master clock is based on UTC?
Also, applications [which generally don't account for leap seconds] would get lurched, sometimes with disastrous results."
Yes, as he said ... sloppy coding.
Whoosh.
You're not describing a problem, you are the problem. If an event occurs during a leap second, you simply timestamp the time, 23:59:60.x. What you describe simply demonstrates the problem with incorrect assumptions and sloppy coding: that a minute can't have more than 60 seconds. That hasn't been the case for over 40 years.
'taint no such thing. There's UTC, and there's POSIX, which is in no way compatible with UTC, which existed long before POSIX. Just another example of brain-dead, incorrect assumptions about timescales.
YRI. You should at least try to understand the subject you're discussing.
"A positive or negative leap-second should be the last second of a UTC month, but first preference should be given to the end of December and June, and second preference to the end of March and September.
- ITU-R TF.460-6.
"National Security is the chief cause of national insecurity." - Celine's First Law
An adjustment of an hour can be a real annoyance, adjusting by a second is lost in the noise. There are much larger consequences if a closk is off by an hour, practically none if it is off by a second. People who grew up before clocks synchronized by radio or the cell network even expect clocks to be off by more than a second but off by an hour is noteworthy..