July/August 2018 issue of acmqueue The July/August issue of acmqueue is out now
Subscribers and ACM Professional members login here

The Bike Shed


  Download PDF version of this article PDF

Error 526 Ray ID: 46e09c0b09c518a0 • 2018-10-23 02:00:20 UTC

Invalid SSL certificate








What happened?

The origin web server does not have a valid SSL certificate.

What can I do?

If you're a visitor of this website:

Please try again in a few minutes.

If you're the owner of this website:

The SSL certificate presented by the server did not pass validation. This could indicate an expired SSL certificate or a certificate that does not include the requested domain name. Please contact your hosting provider to ensure that an up-to-date and valid SSL certificate issued by a Certificate Authority is configured for this domain name on the origin server. Additional troubleshooting information here.


Originally published in Queue vol. 9, no. 4
see this item in the ACM Digital Library



Alpha Lam - Using Remote Cache Service for Bazel
Save time by sharing and reusing build and test output

Jez Humble - Continuous Delivery Sounds Great, but Will It Work Here?
It's not magic, it just requires continuous, daily improvement at all levels.

Nicole Forsgren, Mik Kersten - DevOps Metrics
Your biggest mistake might be collecting the wrong data.

Alvaro Videla - Metaphors We Compute By
Code is a story that explains how to solve a particular problem.


(newest first)

Displaying 10 most recent comments. Read the full list here

Yevgeniy Tovshteyn | Thu, 06 Jul 2017 20:13:05 UTC

Since you mentioned Jewish religion, in Hebrew calendar there are 5 versions of Leap years (another words, 6 versions of year length) and it is so flexible to adjust for any accumulated drift from lunar-solar 19 year cycle.

Bob Frankston | Mon, 06 Jun 2011 19:34:49 UTC

How many seconds in a minute? If you answered 60 you are wrong.

Since we don't keep track of which minute we can't answer that question. That's the problem with leap seconds. It breaks the contract we've made with minutes, hours and days. We don't have such a contract with years and can't convert intervals to years without knowing which interval. And we rarely track which interval  this is a fundamental problem of representation and not a problem of timekeeping nor timescale.

The solution is to keep a separate representation, a correction factor, for those who care. We can then unwind the leap second.

At some point we'll need to address changes in the rotational speed for the earth but for now let's make sure that 60*minutes is correct without knowing which minute.

WB6BNQ | Thu, 26 May 2011 01:00:39 UTC

Wait just a damn minute ! We already have a name for the "NON" leap second version of a time scale. It is called "TAI" meaning Time Atomic International. This is the unmitigated and unmutilated time interval event defined by the accepted (until we change it) Cesium oscillation. As that abbreviation (TAI) does not roll off the tongue very easily, how about calling it UTA meaning Universal Time Atomic ? That rolls off the tongue much more smoothly, has a similar sound to UTC and thus would be less stressful to the general populace. However, the general populace may raise a question of why we would want to back up to a presumed previously discarded standard. Seeing as how c comes after a and denotes c as being a new revised version in common thought, it would be an acceptable question from the unwashed masses. Disclaimer : I only play time keeper on TV; my day job is a retired person.

Poul-Henning Kamp | Mon, 02 May 2011 13:47:00 UTC

John, a lot of ATC systems are really old technology still, but many upgrades are in the pipeline. I have from one person on watch in CPH during the last leapsecond that "it showed us (alarm-)lights we didn't know we had". But ask in Tokyo, Hong Kong or SFO, they get leap seconds during the day.

John | Mon, 02 May 2011 12:42:05 UTC

Interesting that you assert that ATC operators have so little confidence in the reliability of their software and systems. However, as these leap seconds have coincided with year-end rollovers and in one instance Y2K, this may be prudent. ATC is very cautious. Has anyone ever noticed anything awry?

Poul-Henning Kamp | Sat, 30 Apr 2011 22:49:11 UTC

Mike, You clearly have not considered that leap-seconds happen at 23:59:60 UTC time, not local time. Just because we party or sleep through them here in Europe doesn't mean that the rest of the world does. In Tokyo they happen in the middle of the morning and in San Francisco in late afternoon.

Mike Zorn | Sat, 30 Apr 2011 01:13:52 UTC

"A one-second hiccup in input data from the radar is not trivial in a tightly packed airspace around a major airport."

Easily solved: No aircraft in the air between +/- 10 minutes of 12:00:00.000

Another simple fix: save up leap seconds until the Earth is 30 seconds off from "real time". (Since only machines seem to worry about "real time", the inconvenience is minor. People, you'll remember, got on quite nicely for a few hundred years before Pope Gregory XIII stirred things up and convinced people that if they just listened closely, Easter would not be falling in December. Unfortunately, people whose debt payments fell due during the missing week were not amused.)

Mischief may occur if my network is a second or two off from yours, so I appeal again to the "aircraft principle". Everybody gets a New Year's holiday.

"... I would miss leap seconds. They are quaint and interesting, and their present rate of one every couple of years makes for a wonderful chance to inspire young nerds ..."

That's an excellent point. The big problem is, most people are in their sleep cycle during these momentous events. It wold be a boon to both society and science is these leap seconds were to occur at noon. Local noon. After a day, the world would be back in sync. And nobody does anything significant on New Year's Day, anyway. A heresy may arise in insisting that this be done in June, not December, but this can be easily dealt with, in the manner that Middle Age heresies were dealt with.

Matt S | Thu, 28 Apr 2011 15:20:39 UTC

You may not be aware of this, but time synchronization predates computer networks and even computers. At the turn of the 19th Century (20th? Anyway, around 1900) synchronizing clocks on trains systems was a big deal. Figuring out how to get the clocks in Marseille to show the same time as Paris was important. And it was one of the factors that set off Mr Einstein to thinking about the relationship between the speed of light and time itself. I suspect we will have no such scientific revolutions stemming from handling leap seconds.

Clive Page | Thu, 28 Apr 2011 10:16:19 UTC

A small correction to my earlier posting: having checked, my recollection that a spacecraft launch was postponed to avoid the leap second issue seems to be faulty, as the dates don't match. I do vaguely recall something being postponed because of this, but maybe just a software upload to an operating satellite. Sorry about that. ----------------------------- I agree with Rob Seaman that the arguments based on clocks on other bodies are extremely weak. I think the decision ought to be made on a global cost-benefit benefit analysis: are the costs of having leap seconds more than the costs of abandoning the current system? I really don't know for sure, and there seem to be few hard facts available. From what little I know and from assertions made e.g. by bodies involved in telecommunications, air traffic control, etc., my guess is that the cost of leap seconds is significantly higher than the cost of abandoning them. Of course without them solar and civil time will eventually diverge, but that is a problem we can safely leave to our descendants, in my opinion. I doubt if they will be all that put out by a leap minute in say 60 years time, or eveb a leap hour in a few thousand years.

Rob Seaman | Wed, 27 Apr 2011 19:22:11 UTC

Checked back after a week to find that you guys are still chatting away. ("Golly!", to quote Gomer Pyle.)

On the contrary, "certain people" with larger ground-based apertures point out that UTC should remain a kind of Universal Time like the name says. Changing this fact will certainly cost astronomers a lot of time and money. Leap seconds are a means to an end, by all means discuss other ways to meet the UTC project requirements.

But if your idea of the strongest argument against leap seconds is clocks on other rocks, this has been refuted time-and-again. The Martian rover missions keep local Martian *solar* time precisely because even robots respond to diurnal timekeeping requirements. Clocks-on-rocks may not be one of the strongest arguments, but they are one of the oldest (http://iraf.noao.edu/~seaman/leap/leapsec.html#future). By all means attach an appendix to the ITU proposal discussing how eliminating leap seconds permits keeping a "rough link between solar and clock time" on multiple planets. Rather, the ITU simply wants to wish the problem away.

If there is a secretive assembly here, it is the International Telecommunications Union. Between Curie, Pasteur, Laplace and Lavoisier, French speaking scientists have done pretty well for themselves :-)

Displaying 10 most recent comments. Read the full list here
Leave this field empty

Post a Comment:

© 2018 ACM, Inc. All Rights Reserved.