Given the Earth's current speed around the sun and current rate & axis of rotation, what is the best way to keep time to avoid a leap year? How many hours should we have in the day and days in a year would keep things balanced to not need to add or remove days from the year? Further, how many minutes per hour and seconds per minute should we have to avoid a leap second?
Leap years exist for two reasons:
- There are not an integer number of days in a year.
- People perceive a need to keep the seasons where they are on the calendar.
Given the above, there is no way to avoid leap years, or something similar. Defining the calendar year as being a fixed number of days (e.g., 365 days) would result in the seasons shifting by one day per four years.
Leap seconds exist for two reasons:
- The length of a day as measured by an atomic clock is not constant.
- People perceive a need to keep midnight at midnight, noon at noon.
Given the above, there is no way to avoid leap seconds, or something similar. Defining the day as being a fixed number of atomic clock seconds (e.g., 86400) would result in your clock and the Sun disagreeing on mean local noon, but by a very small amount.
That said, there are serious proposals to eliminate leap seconds. Some people such as those who use UTC to timestamp financial transactions do not like them. So far, those proposals have been rejected. The standard response is that it's not UTC that's broken; it's using of UTC in a context where it shouldn't be used that is broken. If you need a monotonically increasing time scale, use TAI or GPS time instead.
This doesn’t really work the way that you are thinking, at least not in a way that is practical for society at all. They problem is that we define a day to be based on Earth rotations relative to the sun, and a year as a full orbit around the sun, and if you find the number of rotations of the earth in a single orbit, it is not an integer (~365.24 rotations (days) in a year). To avoid a leap year, you would need to define the day such that there are an integer number of days in a year (i.e 365 days exactly). The problem with this is that day and night will drift relative to our clocks, and after 2 years, day and night will be switched. The length of the year is also variable and not fundamental, so in order to keep this exact relationship, you'd have to constantly redefine the length of the day, which is not a practical improvement over having leap years.
The leap second has the same type of problem. We want to define the number of seconds in a day as 86400 seconds/day, but the Earth’s rotation is not constant. So, in order to keep clocks from drifting, you have to add leap seconds.
We not only can avoid leap seconds, that's how it used to work in fact. And there is a common newer system which avoids leap seconds as well.
Before 1960, seconds were defined as 1/86400 of a mean solar day. Then when variations in the earth's rotation caused it to get out of sync, a new mean solar day could be computed and divided by 86400 - changing the length of the second in absolute terms, stretching or shrinking it very slightly.
That was a mess, as you can imagine. So the second was defined in terms of a specific number of atomic oscillations which could be made extremely precise. Instead of shrinking and stretching the second to keep an exact number of them in a day, we keep the second fixed and add or subtract one from the (integer) count when we need to adjust.
Those are pretty much the ways to keep earth rotation timing in sync with our clock time - you need some give somewhere, either by changing the length of the second and keeping the count fixed, or you keep the length fixed and change the count. For somebody just writing a simple program to, say, compute the civil seconds between two UTC timestamps, the old way was easier (a fixed count of seconds between two times is trivial). But if you are doing scientific or engineering calculations or experiments to great precision, it's WAY better to have a very firmly fixed length of a second, not changing it from time to time - much worse than the inconvenience of taking leap seconds into account.
But the way, another approach is to just ignore leap seconds and keep your clocks running continuously. That's how GPS time works - it started in sync with UTC, but has not been adjusted for the leap seconds since then, so they are out of sync by a quarter minute or so (I haven't check in some while). That's nice for GPS orbital calculations that cross leap second adjustment boundaries. In the GPS data packet there is information about the current delta between UTC and GPS time so you can calculate civil time from GPS time, as well as a few months advanced warning when a new leap second is going to be added or omitted.
Another answer suggested queuing up leap seconds and making a multi-second leap every decade. That doesn't really simplify your software much tho - now you have to allow minutes with, say, 67 seconds, every decade. Easier to just deal with leap seconds using a table and meanwhile never be off by even 1 second. (The standard allows for them to added or omitted by the way - you could have a 59 second minute or a 61 second minute when you need an adjustment. It's generally the latter tho.
Oh, one other solution. The organization which really tracked all this was called the International Earth Rotation Service, later renamed to International Earth Rotation and Reference Systems Service (IERS). Imagine the chaos if they stopped being funded and the Earth stopped rotating. Anyway, I suppose you could just ask them to rotate it more consistently. :-)
I'm a software engineer, and I can speak about the issue with leap seconds.
They are unpredictable. You don't know far in advance whether you will have one. Code that cares about accurate number of seconds will need some kind of update or feed to continue working correctly.
It's also a step that adds complexity. You have to allow for a minute that contains 61 seconds.
For the first issue, a compromise that keeps reasonable tracking between the Earth's rotation and the time of day would be to allow looser tolerance. Rather than being within one second, correct it on schedule every 10 years. Software doesn't have to worry about year-by-year issues, and the clock stays 7 seconds (or ±4 if you jump ahead) to true.
Given that we already have time zones, the sun will not be exactly at the midnight position at midnight anyway but will be half an hour ahead or behind. Astronomers already need a special offset clock.