<p>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.</p>
<p>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.</p>
<p>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.</p>
<p>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 <em>way</em> 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.</p>
<p>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.</p>
<p>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.)</p>
<p>Oh, one other solution.  The organization which really tracked all this was called the <a href="https://en.wikipedia.org/wiki/International_Earth_Rotation_and_Reference_Systems_Service" rel="nofollow noreferrer">International Earth Rotation Service, later renamed to  International Earth Rotation and Reference Systems Service (IERS)</a>.  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.  :-)</p>

CC BY-SA 4.0
2015-09-18T00:03:51.447Z
2021-11-08T12:53:50.097Z
2021-11-08T12:53:50.097Z
Zeph
<p>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.</p>

<p>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.</p>

CC BY-SA 3.0
2015-09-17T18:06:49.583Z
2015-09-17T23:42:32.197Z
2015-09-17T23:42:32.197Z
tmwilson26
<p>I'm a software engineer, and I can speak about the issue with leap seconds.</p>

<p>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.  </p>

<p>It's also a step that adds complexity.  You have to allow for a minute that contains 61 seconds.</p>

<p>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.</p>

<p>Given that we already have time zones, the sun will not be exactly at the midnight position at midnight <em>anyway</em> but will be half an hour ahead or behind.  Astronomers already need a special offset clock.</p>

CC BY-SA 3.0
2015-09-18T13:50:11.643Z
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.
Steve Jessop
CC BY-SA 3.0
2015-09-18T18:00:19.420Z
@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.
David Hammen
CC BY-SA 3.0
2015-09-18T20:34:14.443Z
@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.
Steve Jessop
CC BY-SA 3.0
2015-09-22T22:48:36.083Z
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](https://en.wikipedia.org/wiki/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.
JonesTheAstronomer
CC BY-SA 3.0
2015-09-22T22:54:33.237Z
Forgot to link to [this](http://physics.stackexchange.com/questions/46823/what-is-the-difference-between-ut0-ut1-and-gmt-time)  discussion which addresses  Universal time.
JonesTheAstronomer
CC BY-SA 3.0
2015-09-17T23:09:18.850Z
2015-09-17T23:09:18.850Z
JDługosz
<p>Leap years exist for two reasons:</p>

<ul>
<li>There are not an integer number of days in a year.</li>
<li>People perceive a need to keep the seasons where they are on the calendar.</li>
</ul>

<p>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.</p>

<p><br></p>

<p>Leap seconds exist for two reasons:</p>

<ul>
<li>The length of a day as measured by an atomic clock is not constant.</li>
<li>People perceive a need to keep midnight at midnight, noon at noon.</li>
</ul>

<p>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.</p>

<p>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.</p>

CC BY-SA 3.0
2015-09-17T22:03:21.920Z
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.
supercat
CC BY-SA 3.0
2015-09-18T00:16:05.533Z
That might seem simpler but I think it's actually more messy that way.   Definition of a second here:   http://physics.nist.gov/cuu/Units/second.html  If you allow "seconds" to vary with the Earth's rotation, then lots of things change with it including the numerical value for the speed of light.  Besides, I don't think it's very disruptive to add or remove a second every 6 months or however often it's done.
userLTK
CC BY-SA 3.0
2015-09-18T01:55:25.510Z
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.
Frames Catherine White
CC BY-SA 3.0
2015-09-18T03:48:58.173Z
Avoiding leap seconds is utterly trivial: don't use SI seconds but what I call "calendar seconds", aka [UT1](https://en.wikipedia.org/wiki/Universal_Time).
R.. GitHub STOP HELPING ICE
CC BY-SA 3.0
2015-09-18T07:44:07.003Z
@supercat - That would be a huge step backwards. From late 1920 to 1972, official time in the US was kept by the radio station WWV. The clocks used to generate that signal had their tick rate modulated to stay within 0.1 seconds of UT2 (a time standard that was officially deprecated in 1972, along with GMT). There are many, many reasons why it is better to have clocks tick at a uniform rate as opposed to a rate dictated by the rotating Earth. If you want a uniform tick rate (and many people do), you'll have to abide with leap seconds.
David Hammen
CC BY-SA 3.0
2015-09-18T13:13:20.813Z
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.
Todd Wilcox
CC BY-SA 3.0
2015-09-18T13:36:21.600Z
@DavidHammen: you don't *have* to abide with leap seconds, you could let mean local noon slip. As Todd says, people live with it being up to 90 minutes out (DST plus half a timezone) and barely notice. Even more in large places with a single time zone, such as China, but there comes a point where it's genuinely inconvenient in practice. I don't think we ever actually need two leap seconds in a year, so the situation really is that we're taking on a responsibility not to just kick the can 3000+ years down the road and let someone deal with a one hour discrepancy.
Steve Jessop
CC BY-SA 3.0
2015-09-18T14:47:48.517Z
@SteveJessop - As I mentioned in my answer, there are serious proposals to eliminate leap seconds. Just let our concept of solar time drift. I'll update my answer to make that stick out a bit more. Regarding the need for more than two leap seconds per year: We came perilously close in the late 1970s / early 1980s; the Earth's rotation rate has sped back up a bit since then. That won't happen forever. The Earth's rotation rate is slowly slowing down. Within a few centuries the concept of only two leap seconds per year will be rather quaint (if we still leap seconds then).
David Hammen
CC BY-SA 3.0
2015-09-18T15:07:15.613Z
@DavidHammen: What I am proposing is not that things just arbitrarily slip, but rather that precise corrections be linearly interpolated over the course of a year.  If "linear time" representing Midnight Jan 1. 2016 UTC is lt0, and "civil time" is ct0, and that year was designated as using long civil seconds, then within that year, the relationship between civil time and linear time would be ct=ct0+(lt-lt0)*60000001/60000000.  Applications which need to track relative time would use linear time (which would simply be a number of seconds since some mark), while...
supercat
CC BY-SA 3.0
2015-09-18T15:10:59.223Z
...applications which needed to track time of day could either use linear time and apply the correction if they had time bases that were more accurate than 16ppb, or simply use a local time base and periodically sync to a civil time base (the more typical action, given that most common time bases are off by a few parts per million anyway).  I'm not sure what is gained by applying corrections a whole second at a time, rather than specifying that they be applied continuously?  How is adding an individual leap second better than adding 525,600,000,000 individual leap picoseconds?
supercat
CC BY-SA 3.0
2015-09-18T16:00:19.330Z
Leap seconds can be avoided by directly using solar time.
Joshua
CC BY-SA 3.0
2015-09-17T18:13:51.630Z
2015-09-18T14:54:48.650Z
2015-09-18T14:54:48.650Z
David Hammen
<p>Given the Earth's current speed around the sun and current rate &amp; axis of rotation, what is the best way to keep time to avoid a <a href="https://en.wikipedia.org/wiki/Leap_year">leap year</a>? 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 <a href="https://en.wikipedia.org/wiki/Leap_second">leap second</a>?</p>

CC BY-SA 3.0
2015-09-18T07:48:44.253Z
Related: [Why do we need to add a second to 30 June and risk upsetting Internet?](http://astronomy.stackexchange.com/questions/8638/why-do-we-need-to-add-a-second-to-30-june-and-risk-upsetting-internet)
David Hammen
CC BY-SA 3.0
2015-09-18T13:23:36.070Z
See also [SMPTE drop time](https://en.wikipedia.org/wiki/SMPTE_timecode#Drop_frame_timecode).
Todd Wilcox
CC BY-SA 3.0
2015-09-18T14:00:35.897Z
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.
Mike Scott
CC BY-SA 3.0
2015-09-18T15:48:48.470Z
@MikeScott Then we just need to speed up earth's orbit around the sun somehow to get rid of leap years.
Ajedi32
<orbit><rotation><time>
How can we avoid needing a leap year/second?
TheSmallestOne
# How can we avoid needing a leap year/second?

(Asked by: username_0 on 2015-09-17)

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](https://en.wikipedia.org/wiki/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](https://en.wikipedia.org/wiki/Leap_second)?

**Tags:** orbit, rotation, time

> **Comments:**
> **username_1**: Related: [Why do we need to add a second to 30 June and risk upsetting Internet?](http://astronomy.stackexchange.com/questions/8638/why-do-we-need-to-add-a-second-to-30-june-and-risk-upsetting-internet)  
> **username_2**: See also [SMPTE drop time](https://en.wikipedia.org/wiki/SMPTE_timecode#Drop_frame_timecode).  
> **username_3**: 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.  
> **username_4**: @username_3 Then we just need to speed up earth's orbit around the sun somehow to get rid of leap years.  

---

## 4 answers

### Answer by username_1 on 2015-09-17. Score: 20 | Accepted answer

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.

> **Comments:**
> **username_10**: 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.  
> **username_11**: That might seem simpler but I think it's actually more messy that way.   Definition of a second here:   http://physics.nist.gov/cuu/Units/second.html  If you allow "seconds" to vary with the Earth's rotation, then lots of things change with it including the numerical value for the speed of light.  Besides, I don't think it's very disruptive to add or remove a second every 6 months or however often it's done.  
> **username_12**: 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.  
> **username_13**: Avoiding leap seconds is utterly trivial: don't use SI seconds but what I call "calendar seconds", aka [UT1](https://en.wikipedia.org/wiki/Universal_Time).  
> **username_1**: @username_10 - That would be a huge step backwards. From late 1920 to 1972, official time in the US was kept by the radio station WWV. The clocks used to generate that signal had their tick rate modulated to stay within 0.1 seconds of UT2 (a time standard that was officially deprecated in 1972, along with GMT). There are many, many reasons why it is better to have clocks tick at a uniform rate as opposed to a rate dictated by the rotating Earth. If you want a uniform tick rate (and many people do), you'll have to abide with leap seconds.  
> **username_2**: 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.  
> **username_8**: @username_1: you don't *have* to abide with leap seconds, you could let mean local noon slip. As username_2 says, people live with it being up to 90 minutes out (DST plus half a timezone) and barely notice. Even more in large places with a single time zone, such as China, but there comes a point where it's genuinely inconvenient in practice. I don't think we ever actually need two leap seconds in a year, so the situation really is that we're taking on a responsibility not to just kick the can 3000+ years down the road and let someone deal with a one hour discrepancy.  
> **username_1**: @username_8 - As I mentioned in my answer, there are serious proposals to eliminate leap seconds. Just let our concept of solar time drift. I'll update my answer to make that stick out a bit more. Regarding the need for more than two leap seconds per year: We came perilously close in the late 1970s / early 1980s; the Earth's rotation rate has sped back up a bit since then. That won't happen forever. The Earth's rotation rate is slowly slowing down. Within a few centuries the concept of only two leap seconds per year will be rather quaint (if we still leap seconds then).  
> **username_10**: @username_1: What I am proposing is not that things just arbitrarily slip, but rather that precise corrections be linearly interpolated over the course of a year.  If "linear time" representing Midnight Jan 1. 2016 UTC is lt0, and "civil time" is ct0, and that year was designated as using long civil seconds, then within that year, the relationship between civil time and linear time would be ct=ct0+(lt-lt0)*60000001/60000000.  Applications which need to track relative time would use linear time (which would simply be a number of seconds since some mark), while...  
> **username_10**: ...applications which needed to track time of day could either use linear time and apply the correction if they had time bases that were more accurate than 16ppb, or simply use a local time base and periodically sync to a civil time base (the more typical action, given that most common time bases are off by a few parts per million anyway).  I'm not sure what is gained by applying corrections a whole second at a time, rather than specifying that they be applied continuously?  How is adding an individual leap second better than adding 525,600,000,000 individual leap picoseconds?  
> **username_14**: Leap seconds can be avoided by directly using solar time.  

---

### Answer by username_5 on 2015-09-18. Score: 6

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)](https://en.wikipedia.org/wiki/International_Earth_Rotation_and_Reference_Systems_Service). 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. :-)


---

### Answer by username_6 on 2015-09-17. Score: 4

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.


---

### Answer by username_7 on 2015-09-17. Score: 3

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.

> **Comments:**
> **username_8**: 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.  
> **username_1**: @username_8 - 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.  
> **username_8**: @username_1: 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.  
> **username_9**: 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](https://en.wikipedia.org/wiki/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.  
> **username_9**: Forgot to link to [this](http://physics.stackexchange.com/questions/46823/what-is-the-difference-between-ut0-ut1-and-gmt-time)  discussion which addresses  Universal time.  

---

