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?

  • $\begingroup$ Related: Why do we need to add a second to 30 June and risk upsetting Internet? $\endgroup$ Sep 18, 2015 at 7:48
  • $\begingroup$ See also SMPTE drop time. $\endgroup$ Sep 18, 2015 at 13:23
  • 3
    $\begingroup$ All we need to do is drop Mount Everest into the Marianas Trench. That should speed up the Earth's rotation enough that leap seconds are no longer necessary. $\endgroup$
    – Mike Scott
    Sep 18, 2015 at 14:00
  • $\begingroup$ @MikeScott Then we just need to speed up earth's orbit around the sun somehow to get rid of leap years. $\endgroup$
    – Ajedi32
    Sep 18, 2015 at 15:48

4 Answers 4


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.

  • $\begingroup$ What difficulties would arise if separate units were created for "long civil second", "median civil second", and "short civil second", with the first being defined as being one part in 60 million longer than a "normal" second, the middle being a "normal" second, and the last defined as being one part in 60 million shorter, and civil time were specified as switching among the different kinds of seconds for different years? Applying a 1 microsecond per minute correction for a year would seem less disruptive than occasionally applying a one-second correction all at once. $\endgroup$
    – supercat
    Sep 17, 2015 at 22:03
  • 1
    $\begingroup$ Most proposals to get rid of leap seconds are based around simply allowing midnight/noon to be wrong. Since they would only become noticeably wrong after centuries, particularly because timezones are off by tens of minutes depending where you are. $\endgroup$ Sep 18, 2015 at 1:55
  • 2
    $\begingroup$ We could avoid leap seconds if we were okay with solar time and atomic time being unrelated things. $\endgroup$
    – user253751
    Sep 18, 2015 at 2:28
  • 2
    $\begingroup$ Avoiding leap seconds is utterly trivial: don't use SI seconds but what I call "calendar seconds", aka UT1. $\endgroup$ Sep 18, 2015 at 3:48
  • 1
    $\begingroup$ For completeness sake, it's worth noting that we are actually OK with noon and midnight being wrong in the U.S. (and other places) for about half a year: during Daylight Saving Time. And now that I think about it, for most of a time zone, the sun is not directly overheard at noon. Between Washington, DC and Ohio, the solar time changes by about an hour (the sun rises about an hour later in Ohio), but they are in the same time zone. $\endgroup$ Sep 18, 2015 at 13:13

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.

By 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 checked 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 though – 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 though.)

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. :-)


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.


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.

  • $\begingroup$ Also as a software engineer, I would point out that for most things internet-connected, and a lot of things that aren't, you actually expect the clock to be corrected from time to time anyway, and by increments more than a second. So much of the time leap-seconds are covered by the same allowances you make for clock corrections. But when they matter (such as in GPS) they really matter, so they add design complexity to support people who need them, and this sometimes inconveniences even those who don't. $\endgroup$ Sep 18, 2015 at 13:50
  • $\begingroup$ @SteveJessop - GPS time does not have leap seconds. GPS time, or TAI, is what a software engineer who absolutely needs a monotonic time scale should be using. Using UTC and complaining that it has leap seconds -- that's a "Doctor, it hurts when I do this:《 bonk 》" kind of thing. The solution is simple: Then don't do that. $\endgroup$ Sep 18, 2015 at 18:00
  • $\begingroup$ @DavidHammen: right, which is why when using GPS as a time source you need to add the leap seconds back in, and you'll get the time wrong (from the POV of the rest of the world) if you don't. $\endgroup$ Sep 18, 2015 at 20:34
  • $\begingroup$ The sure way to avoid timing problems with computers is not to work in UTC with its leap seconds, but to work at the lowest level: Sidereal Time ("star time") or Universal time (UT1) which astronomers use to set their telescopes and satellites to absolute pointing positions. That can be easily converted to "local" time in any system, GMT, EST, UTC, GPS, and so on. The irregularities in the Earth's rotation are tracked carefully and values of UTC-UT1 are always available. $\endgroup$ Sep 22, 2015 at 22:48
  • 1
    $\begingroup$ Forgot to link to this discussion which addresses Universal time. $\endgroup$ Sep 22, 2015 at 22:54

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .