Slashdot Mirror
Leap Second May Be On the Chopping Block (ieee.org)
szotz writes: The days of 61-second minutes may be coming to an end. The World Radiocommunication Conference is meeting for nearly the entire month of November, and one of the hot-button issues is what to do about the leap second. The addition to UTC is supposed to keep atomic time aligned with Earth's rotation, but past leap seconds have caused server crashes, and some are worried that future problems could be even worse. Going into the conference, it doesn't look like there's much of a consensus on what to do. One official is expecting weeks of debate.
So people write crappy code and rely on it without adequate fault tolerance strategies and that's somehow the problem of people who measure time? I think not.
John
While I'm sympathetic for all the folks who want to drop the leap second, given an appropriate amount of time the difference will add up. It seems to me the problem is quite simple which is to publicize the leap second a bit more than it is now. It is an education issue -- at least no more or less than leap days and that seems to work just fine all in all.
Perhaps Facebook can create a viral leap second post. Much better than viral kitty posts.
I like to hang out at Area 15. Less security and you glimpse an occasional dyslexic alien.
Table-ized A.I.
Midnight is always 00:00. There is no such hour as 24:00, but alas the ID10Ts at apple think there is and put one into Yosemite.
The problem isn't the system, it is the software and databases that require millisecond accuracy.
The problem is that time is not as linear as we think it is. Even accurate clocks can start having time shifts in relation to each other. This is all spelled out in Physics and is (or at least, should be) well known.
We need to change how we keep track of time, in a way that isn't linear.
Agent K: A *person* is smart. People are dumb, stupid, panicky animals, and you know it.
In my 35 years, I've always seen time as a counted measure of how much time has passed since I started counting. I seem to be forever learning that's my novel idea.
Why should I care where the sun is, where the moon is, where the earth is, with respect to time? If it's winter, I can start work at 9, I can start at 10, I can start an hour after sunrise. I don't need to adjust my clock to start work at the same clock-display every day. I see nothing wrong with a company that has different business-hours by the season.
Similarly, since I'm not in the old west, I don't care if "high noon" is an noon, or 1, or 1 second after noon. I've never determined the time based on the sun.
Last I checked, we have perfectly wonderful time-keeping and gps devices these days. So ocean ships and submarines no longer need a sextant and a chronometer to figure out when and where they are.
So here's my petition. I'd like time to always move forward, and the same rate of 1 second per second. I'd like it to not jump, leap, crawl, rewind, fast forward, restart, end , or eject.
Shit, I just realized that I'm not 35 years old. Or I am 35 years old, but not when measured in seconds. Wait for it...ok, now I'm 35 years old. Phew.
There are plenty of systems for time that *don't* involve leap seconds.
If your system's too crappy to be able to deal with leap seconds or you don't have a way to update them, use TAI or GPS time.
Don't screw with the definition of UTC just because you can't handle the complexities of it. It's not like someone's forcing you to use UTC, UT1R, or one of the other UT systems that are specifically intended to deal with issues of local noon.
(disclaimer: I work for a group that deals with solar observations*)
* and even one of them almost screwed the pooch and didn't distribute the update for the June/July 2015 leap second until 3 days before it happened ... and of course it was compiled in (for speed, they claimed**) rather than be an external file.
** if it really was for speed, then they need to flip their giant if/then structure so it starts in the present and walks backwards in time, rather than how they're doing it now where it runs dozens of tests that will always fail for a spacecraft that wasn't launched 'til 2010.
Build it, and they will come^Hplain.
The days of 61-second minutes may be coming to an end
Wait... are they getting rid of days, seconds, or minutes?
systemd is Roko's Basilisk.
Leap-seconds were properly handled in computer software before most of today's software engineers and programmers were born.
Back in 1969, I started working on a software system that already handled leap-seconds quite smoothly. At that time, keeping UTC aligned with the rotation of the earth involved introducing fractional seconds and also having UTC seconds NOT the same duration as atomic seconds (TAI). In 1972, this was simplified by having UTC seconds exactly the same duration as TAI seconds and (after an initial fractional leap) introducing only leaps that were full seconds. The software in the system on which I was working DID NOT HAVE TO CHANGE!!.
Internally, the system on which I was working -- which evolved and continued in use to operate military space satellites for over 20 years -- kept all time in TAI, which never has leap-seconds. A relatively small routine converted in either direction between UTC for displays and TAI for internal time. Another small routine converted from UTC to UT! to sidereal time, the latter more closely reflecting the rotation of the earth, which is gradually slowing and also has predictable periodic fluctuations. The purpose of all this was that we needed to know very accurately the spot on the rotating earth directly under the orbiting space satellite. The position of the satellite was known in TAI while the surface of the earth was rotating very closely to sidereal time.
Also note that the network time protocol (NTP) also accounts for leap-seconds and has done so for decades.
I can only conclude that the current attempt to do away with leap-seconds is a result of lazy software "professionals" trying to shift blame for their ignorance about leap-seconds.
Incompetent people like to shift problems to someone else. They're already trying to shift problems like "national debt", pollution,and "climate change" to the future generations and now they want to shift another problem to a future generation.
I would prefer better coding and testing standards to be the norm. At the moment, every time a problem occurs because of a "leap second" it's noticed and fixed with a reminder that this is something to be watched and tested for. I would like to think that handling it would become part of the standard QA procedures, actually it should have already been part of QA, it's not new, this has been happening for over 40 years!
If they think a "leap second" is a big deal then a "leap minute" or "leap hour" is going to really cause problems. They'll have longer periods of time for more bugs to accumulate and when they happen everything will have problems because either they'll fail or something they depend on will fail.
"How close do we need to be to the astronomical time?"
For UTC, within 1 second. That's what it was created for, to follow Sol, just like the other UTx timescales.
For those who don't care, there are timescales which don't have leap seconds - TAI, GPS, etc. Use them instead of trying to redefine UTC to be completely decoupled from its intended purpose.
This issue isn't leap seconds, it's lazy or stupid programmers or committees who don't or won't understand how UTC works.
"National Security is the chief cause of national insecurity." - Celine's First Law
in the same time, we could get rid of summer/winter time change
aaaaaaa
We let "one year" drift enough that it only needs to be corrected once it's off by a whole day. Why not let [86,400] seconds accumulate and have a second leap day every hundred thousand years or so?
Because sunlight levels over a day control more recurring human biological processes, such as alertness, than any natural phenomenon with a year's period.