That principle is more of a koan than actual concrete advice.

For example, deleting your entire codebase and firing all your developers is painful, but even the most continuous deliverer wouldn't advise you to do that more often.

Do you also pee in front "wet floor" signs?

Getting past pedantry, the advice is obviously about foreseeable, repeating parts of normal business, and it applies to more than devops.

A long time ago (tail end of the "desktop publishing revolution"), I was a production assistant, and then manager at a magazine. We published six times a year. Towards the end of my first year there, I realized we had the same problems, right down to our Advertising Director's emotional meltdown, every. single. issue.

After getting to know folks working at other magazines and people at our press, I noticed that the monthlies seemed to run smoother with less drama, and the weeklies were even better at it. Eventually I realized it was because they had to be. If there was some minimum amount of human drama that had to happen, it was forced into exhibitions that didn't disrupt the (tight) schedules. If last-minute changes from flakey advertisers came in, they didn't cause a firedrill, they just didn't run, because that issue is already on the press and we're talking about the issue after next now. And so on.

The general principle is actually very straightforward, and applicable all over the place, including your personal life. If you have high-friction processes, devoting time and attention to them is the way you make them lower-friction processes. And while it may be possible to do that without doing things over and over until you get there, it probably is not possible for you to get there without repetition, else you'd not have the problem in the first place.

Doesn't every company do this slowly as they replace code and developers?

> So, if leapseconds are actually painful for you, then maybe we need to contemplate making this kind of adjustment on a finer timescale, like milliseconds.

That is what a lot of organizations do, "smearing" the leap second since they know their systems can't handle the discontinuity. I think this shows that software has failed in general at handling leap seconds correctly. As another said, I think leap seconds are unnecessary complexity with the frequency at which they happen.

On the contrary, I think that the smearing behavior is an indication that leap seconds poison an otherwise-useful model of reality. The discontinuity is an annoying edge case driven by the fact that "time error" accumulates, so it seems to me that that a 1-day smear is a more natural approximation than an instantaneous discontinuity. That, and tuned for the attention span of human organizations.

>The third principle of Continuous Delivery is "If something is difficult or painful, do it more often".

That only works assuming you need to do it at all.

If leap seconds are useless (to the majority of users) or insufficient, not doing them is preferable to doing them constantly.

That third principle is about facing (and implicitly, automating) your difficult-but-necessary processes. Outside of that narrow scope it's terrible advice. Being in a car crash and converting a country from one system of units to another are both difficult and painful and you should do either as seldom as possible.

The obvious correction is to change the duration of a second such that a year is exactly $integer seconds long. While this will make the duration of second drift from year to year, that drift is so small that everyday devices like consumer-grade computers could just ignore it, provided they're NTP synced once every five years or so. Physicists can just keep using whatever they're using and call it by a different name. Ideal solution all-around.

The core issue is that the number of days per year is messy, so it's not possible to have a 'nice' number of seconds in a day and also in a year.

The best solution is probably just to use a nice number of seconds per day and accept the fact that in 100ish years summer will start in March, not December. It's not like we need to build our entire society around planting and harvest any more.

That's not anywhere close to "the best solution"

This discussion isn't going to be very meaningful unless you wanna tell us what 'best' means to you.

Are we to infer that your lack of criteria for "best" in your own post means that it too is meaningless? You made a breath-taking leap going from {our society isn't as dependent on planting and harvesting anymore} to {therefore it's "probably best" to radically alter universal concepts of temporality to partially solve an obscure technical problem}. Methinks the burden on proof lies firmly in your court on this one.

I'm not the one arguing with a statement in that post.

That's fair. I simply can't see the best solution relying on getting rid of deeply ingrained culutural norms that span thousands of years.

March is already summer here (Southern Hemisphere). We have all sorts of weird eccentricities due to "cultural norms" (we use snowflakes on our Christmas cards in mid-summer, whereas the Steam Summer Sale happens mid-winter).

Not to mention with climate change, we're probably going to have to deal with many other changes in season etc. anyway.

All of us deal with the fact that the day gets shorter and longer every year anyway (and daylight savings didn't seem to be a terribly good solution).

I think having the seasons slowly drift is a non-issue, provided it's just slow enough to not be noticeable from year to year.

Yeah, I can see that being an issue, at least until a decent proportion of humanity lives off-world. I can't see people living in the asteroid belts adding arbitrary leap-seconds.

Of course, once you start dealing with astronomical distances and speeds, the whole concept of a single universal measure of time kind of goes out the window anyway so it's probably going to get worse, not better. :P

(FWIW my definition of 'best' here is something along the lines of 'simple, no special rules or tinkering, gets translated to a human-readable local time on demand'. Which is pretty much how Unix epoch works, come to think of it.)

Yes... let's let future asteroid dwellers solve their own problems, which will be as much cultural as technical. Today's elegant universal solution is sometimes tomorrow's Esperanto: perfectly useless.

But we do build our entire society around sports seasons.