The US has put forth a proposal to abolish leap seconds. It is now supported by China, Australia, Japan, and South Korea. The ITU keeps punting on actually voting on it - it's now scheduled for 2023.
https://en.wikipedia.org/wiki/Leap_second
A day already drifts... every single day in fact. Why is 0.9 sec the magic threshold for maximum drift? Why can't it be 1 minute of drift, or 1 hour of drift? We are putting out problematic corrections for something a minor drift on the scale of years that should be happening on the scale of centuries or millennia in my opinion.
The Earth's rotation is slowing down (by about 2 ms per day per century), so the difference between TAI and UT1 is increasing quadratically, not linearly.
Imagine what would happen when the International Date Line ends up in the middle of the US.
If the drift is about 0.5 second per year, about a minute of drift will have to be compensated on a century border.
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.
OTOH, if you think leapseconds are painful now, just you wait until you postpone this pain and do it even less frequently.
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.
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.
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.
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.
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.
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.
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.)
This has nothing to do with leap seconds. Leap seconds are the worst mechanism in keeping time, there's not a single advantage to having leap seconds.
> A day is defined as the rotation of the earth around its axis.
And we can now measure time with precision high enough that tying to Earth's rotation is not acceptable. We can still use timezones to fix the shift.
> Changing any of these will make the summer drift into the winter, or the night into the day, or whatever.
Yeah, and it will take a millennium for Earth rotation to shift enough for people to notice it. On the other hand, you'd have no problem with summer/winter time I presume?
No, I don't, as they are just views on a monotonically increasing time scale named UTC that keeps up with Earth's rotation, so that every single thing from climate diagrams to everything else humanity is syncing on keeps working and being comparable.
> We can still use timezones to fix the shift.
Or, we could not do that. Everyone is free to use TAI inside their own projects as they see fit if they have the needs for strictly monotonically increasing time. I would argue that leap second smearing has way less artifacts in practice than bolting time zones onto a shifting UTC time.
Leap days, sure.
Leap seconds - as the article points out, there have only been 27 so far since 1970. Less than a minute per century isn't much drift, and could be corrected in a bigger block later.
When you get into the world of programming for most people, businesses especially, a day is defined as 24 hours. We like to think that our days and months and years are tied to vast astronomical forces, for romantic reasons, but when it comes down to it, everything comes back to the second, and the second is defined to be a single unvarying length of time.
In TAI: A day is 24 hours (86400 seconds always), and a second is a SI second.
In UTC: A day is a rotation of the earth, and a second is a SI second. (And since these are incompatible, we have to introduce leap seconds).
In UT1: A day is a rotation of the earth, and a second is 1/86400 of a rotation of the earth.
Julia, interestingly, uses the UT1 notion, thus avoiding leap seconds, IIRC.
If you want to nitpick, you're going to need to start with Cesium-133 oscillation periods as averaged from over nine billion samples.
This matters when computers are bouncing records about time around satellites and across the global.
Edit: I have no idea what I’m talking about so please do not hesitate to correct me on the particulars!
A bit like complaining that UTC is wrong because it doesn't match your local Solar time.
Best to define a second as a certain distance light travels in a vacuum and use that to build minutes, hours, etc. Then, have a fixed geo reference point (like, say, geo 0:0) that holds an atomic clock as a main reference.
We are only really talking about local coordinate changes in the time dimension, really, so might as well simplify.
I would prefer to call it quasiperiodic.
The speed of the Earth's rotation is slowing over time. Therefore leap seconds are becoming more and more common. In a century, we should be averaging something like 1 a year. In 500 years, we should be averaging one every few months. And so on.
It took over a thousand years for the Julian calendar to fall apart. Our current timekeeping system will also fall apart eventually, and I would be surprised if it lasted as long.
Regardless, we've had maybe half a minute of drift since the 1970's. If the drift is 1 minute in the 2000's, 1 second per year in the 2100's, 2 seconds per year in the 2200's, 3 seconds per year in the 2300's, etc., then by 2500, the cumulative drift would add up to...60 + 100 + 200 + 300 + 400 + 500 or 1560 seconds of total cumulative drift by 2600. That's less than half an hour. If we didn't bother accounting for leap seconds, UTC midnight would be only half an hour off from astronomical midnight in 600 years, which is roughly the same error inherent in most time zones.
It will take on the order of a thousand years for the discrepancy to add up to an hour. In 5000 years, it will be around a day. The fact that it is currently growing about a minute per century is true, but not a good predictor of what will happen.
That said, I prefer if we just lose the astronomical basis for time keeping, and let our distant descendants figure out that they should use time zones, and not modify UTC. Hopefully by the time it becomes obvious that clocks are drifting too fast for time zones to change all of the time, we're a multi-planetary species and paying attention to what is happening on the Earth seems quaint.
B. If you want to be super strict about it, as I imagine you do, that scheme would hit problems with relativistic effects. Local time is the only real time.
>A year is defined as the rotation of the earth around the sun.
Sounds like we need a generic geo-solar measurement.
Right now those two things are intertwined, and that's bad. Not everyone eats lunch around noon or go to bed at 23:00 anyway, so the cultural part is very fuzzy.
I should be able to describe time in an almost metric way. A unit that is the same no matter where I am in the world and doesn't change based on how fast a rock moves around a fireball. "Hey person in Japan, let's have a video meeting at 1,234,99" where that number means the same thing to the as it does to me. Its going to be dark for one of us and bright for another.
Then we can have a different unit, let's call it "day offset". That is the offset from the first number that dictates when a particular area considers to be "the day", when the average people wakes up, have lunch, have dinner, go to bed.
"Let's meet at 1,234,99. I know you're in Japan and your offset is +9,23 while here it's "-5,78" so it's a bit inconvenient, but hopefully you can make it!"
Yes, I realize I'm roughly describing how time and timezone works, with an important difference: with the current system, people live around the adjusted number. The number after the timezone is applied. After the leap seconds and all that crap is applied. Some people argue about daylight saving or no. Computers have to deal with all of it. Let's make the non-adjusted number what people use day to day, and the "offset" is a static number picked by the locals, that include stuff like daylight saving, leap seconds, and various other cultural adjustment. Its only purpose is to communicate the cultural or location difference between 2 people.
Obviously that will never happen, but Ill keep dreaming.
That being said, why your approach doesn't work is that there are several hard astronomical or cultural definitions that you'd throw off by playing with time.
A day is defined as the rotation of the earth around its axis.
A week is a hard cultural and religious boundary for just about everything in life.
A month is roughly the rotation of the moon around the earth (although that definition is arguably the weakest and ready to go)
A year is defined as the rotation of the earth around the sun.
Changing any of these will make the summer drift into the winter, or the night into the day, or whatever.
Time just isn't simple, and although most of these intervals _almost_ fit within each other, reality is that they don't and we'll always have artifacts.
If you enjoy philosophy on these kinds of imperfections as much as I do, I can heavily recommend this article about musical tuning: https://blogs.scientificamerican.com/roots-of-unity/the-sadd...