<p>Short answer: UT1</p>

<p>Long answer:</p>

<p>The <a href="https://en.wikipedia.org/wiki/Julian_day" rel="nofollow noreferrer">Julian Day</a> (JD) is just a consistent day count since the beginning of the Julian period, that is January 12th 4713 BC. As the numbers tend to be large (today is day 2,458,557.5), in the 80's and motivated by computer memory limitations, the reduced JD was created which is just <span class="math-container">$JD-2400000$</span>. Then, to remove the annoyance that the Julian Day starts at midday instead of midnight, the Modified JD (MDJ) was created, which is just <span class="math-container">$JD-2400000.5$</span>.</p>

<p>By definition the MJD zeroes at solar noon at the 0° meridian. Therefore, it is not a regular time measure, it is tied to Earth's rotation and accelerates or decelerates depending on minute variations of Earth's rotating speed.</p>

<p>You can use basically any solar time including all flavors of UT time to define your MJD, but the most precise is UT1.</p>

<p>But UT1 is not a regular measure of time either, and is also affected by variations on Earth rotation speed. The only really regular time standard among the ones you mention is UTC, which is based on atomic clocks. Being regular, the solar noon drift off UTC and doesn't happen at 12:00 h UTC, therefore, <a href="https://en.wikipedia.org/wiki/Leap_second" rel="nofollow noreferrer">leap seconds</a> are added to keep UTC reasonably close to solar time. But a record of leap seconds is kept so you can use UTC to precisely measure time intervals independently of the variations of Earth's rotation.</p>

<p>In that sense UT1 and UTC are not two flavors of the same thing as you suggest, they actually measure two completely differing things. The first measure Earth's rotation and the second measures time. Due to the same reason, MJD cannot or should not really be referenced to UTC (otherwise it would not zero solar noon).</p>

<p>Said this, in those bulletins the MJD conveys exactly the same information than the date. So "2019 1 2" meaning January 2nd 2019, conveys exactly the same information than MDJ 58485, it is just a more machine friendly way to refer to a specific day. And it also removes the need to account for missing calendar days if you work with dates relatively far in the past.</p>

<p>Now if you want to know how much time have elapsed between two entries in the table, you need to know how to transform whatever version of solar time they use (UT1 in this case), to a regular time reference like UTC or <a href="https://en.wikipedia.org/wiki/International_Atomic_Time" rel="nofollow noreferrer">TAI</a>. That's why the "UT1-UTC" value is included. In any case, in doing such calculation you need to take in account any leap seconds added to UTC between the time of the two entries.</p>

<p>Does that makes sense?</p>

CC BY-SA 4.0
2019-03-16T02:18:09.423Z
Re *Does that make sense?* Yes, it does makes sense, except for one thing, which is that leap seconds always occur on the date when leap seconds are are injected rather than the day after if UT1 was used for MJD. For example, UT1-UTC jumps from -0.557 seconds on 1992/06/30 to +0.443 seconds on 1992/07/31, from -0.408 seconds on 2016/12/31 to +0.591 seconds on 2017/01/01. This is consistent for all points where leap seconds were injected. But since UT1 was behind UTC at midnight on those dates, the value of UT1-UTC should still be negative at those exact dates. But it isn't.
David Hammen
CC BY-SA 4.0
2019-03-16T02:21:14.707Z
Perhaps it's a proleptic UT1? Or perhaps it's UTC, but that makes for a bit of a mess with regard to interpolating pole positions across leap second boundaries.
David Hammen
CC BY-SA 4.0
2019-03-16T09:07:58.670Z
I was being stupid. Since UT1 is behind UTC at a point where a positive leap second is added to UTC, UT1 reaches midnight after UTC does, which means the leap second has already been added to UTC. Thus the shift from a negative UT1-UTC value to a positive value will occur on the day a positive leap second is added to UTC. The change will only show up a day later if a negative leap second is added to UTC. But the odds of that happening are essentially nil given that the Earth's rotation rate is gradually slowing down.
David Hammen
CC BY-SA 4.0
2019-03-16T17:13:16.827Z
Yes. And you shouldn't worry much about that. Just transform the times to UTC, and use those to times for the interpolation. As your data points are spaced every one day, the maximum error in the interpolation will be a fraction of a second, if you worry about that kind of accuracy concerns you can then make an exception for days when a leap second was added.
Camilo Rada
CC BY-SA 4.0
2019-03-16T17:57:34.620Z
UTC is not uniform; it has leap seconds. That said, a decent (not even great) interpolation algorithm can handle non-uniform abscissae. What I want is a way to determine TAI-UT1 and X and Y pole positions as functions of either UT1 or TAI. I view UTC as something for civilian use only; it was in my opinion a mistake to tie UTC to both UT1 and TAI, and do so at the second level. Doing so has resulted in a significant amount havoc and with a negligible benefit. But that's water under the bridge.
David Hammen
CC BY-SA 4.0
2019-03-16T18:01:23.033Z
@DavidHammen Absolutely, turning times into TAI and then doing the interpolation removes most complications, the you can bring your interpolated values back to UT1 or UTC.
Camilo Rada
CC BY-SA 4.0
2019-07-22T11:39:20.113Z
UT1 always has a "day" of 86400 "astronomical seconds", so that the 86400/24:00:00 lapse means one true, complete Earth rotation no matter what. This means are _not_ the same as metric (SI) seconds and vary in length, though a human won't be able to perceive the difference. TAI, and thus UTC, tick metric time, not astronomical time. TAI is a simple, true linear clock (current at 1.942 4867 Gs from its year 1958 epoch as of this posting), UTC though tries to adjust itself so its time-of-day (TOD) value is within 1 s of that of UT1 by adding or removing seconds ("leap seconds").
The_Sympathizer
CC BY-SA 4.0
2019-07-22T11:43:33.957Z
Hence, converting UT1 to TAI is not easy. You need essentially a graph of the length of the astronomical seconds in true metric seconds since the TAI epoch and then you integrate that. And good luck with extrapolation of the scale into the past...
The_Sympathizer
CC BY-SA 4.0
2019-07-22T11:46:14.897Z
IMO we should just "boil the ocean", use TAI as the basis of timekeeping directly (just mod 86400, there you go, there's a time-of-day for civil use, who cares about noon being so precise) and map Earth rotation intervals onto it as a secondary recording for astronomical purposes (what really should be a graph of _angle_ versus _time_.). But meh, we're buried up way past the top of our heads in legacy cruft :g:
The_Sympathizer
CC BY-SA 4.0
2019-03-15T19:08:52.847Z
2019-03-15T20:16:24.450Z
2019-03-15T20:16:24.450Z
Camilo Rada
<p>Apparently, the IERS publishes values for each 0 h of UTC in their bulletins. I myself thought otherwise, but I recently noticed, in a geodesy exam, that they mentioned UTC for the daily parameters.</p>

<p>Upon closer look at the Bulletins themselves, I was able to confirm this:</p>

<p><a href="https://i.sstatic.net/AFVFI.jpg" rel="nofollow noreferrer"><img src="https://i.sstatic.net/AFVFI.jpg" alt="enter image description here"></a></p>

<p>Although using UT1 instead of UTC for interpolation should cause only tiny errors, smaller than the posted errors of the final values.</p>

CC BY-SA 4.0
2019-07-16T16:59:24.010Z
2019-07-16T16:59:24.010Z
FSimardGIS
<p>IERS <a href="https://datacenter.iers.org/data/latestVersion/13_FINALS.DAILY_IAU2000_V2013_0113.txt" rel="noreferrer">Bulletin A</a> and <a href="https://datacenter.iers.org/data/latestVersion/207_BULLETIN_B207.txt" rel="noreferrer">Bulletin B</a> contains Earth orientation parameters. These include the time difference between UT1 and UTC and pole position. The values for these parameters are listed once per day, keyed by "MJD" (Modified Julian Date).</p>

<p>The documentation does not say which time scale these MJD values reference. Without qualification, MJD is typically taken to mean some flavor of Universal Time. If that is the case, which flavor of universal time is it: UTC, UT1, or some other flavor? If that's not the case, which is it?</p>

<p>I'm using the data in an interpolative fashion (Lagrange interpolation) to estimate the Earth orientation parameters at arbitrary points in time, so not having the correct time standard will lead to small errors in the interpolated values.</p>

<geophysics><planetary-science><earth-rotation><earth-observation>
Time standard for IERS Bulletin A
David Hammen
# Time standard for IERS Bulletin A

(Asked by: username_0 on 2019-03-15)

IERS [Bulletin A](https://datacenter.iers.org/data/latestVersion/13_FINALS.DAILY_IAU2000_V2013_0113.txt) and [Bulletin B](https://datacenter.iers.org/data/latestVersion/207_BULLETIN_B207.txt) contains Earth orientation parameters. These include the time difference between UT1 and UTC and pole position. The values for these parameters are listed once per day, keyed by "MJD" (Modified Julian Date).

The documentation does not say which time scale these MJD values reference. Without qualification, MJD is typically taken to mean some flavor of Universal Time. If that is the case, which flavor of universal time is it: UTC, UT1, or some other flavor? If that's not the case, which is it?

I'm using the data in an interpolative fashion (Lagrange interpolation) to estimate the Earth orientation parameters at arbitrary points in time, so not having the correct time standard will lead to small errors in the interpolated values.

**Tags:** geophysics, planetary-science, earth-rotation, earth-observation


---

## 2 answers

### Answer by username_1 on 2019-03-15. Score: 3 | Accepted answer

Short answer: UT1

Long answer:

The [Julian Day](https://en.wikipedia.org/wiki/Julian_day) (JD) is just a consistent day count since the beginning of the Julian period, that is January 12th 4713 BC. As the numbers tend to be large (today is day 2,458,557.5), in the 80's and motivated by computer memory limitations, the reduced JD was created which is just $JD-2400000$. Then, to remove the annoyance that the Julian Day starts at midday instead of midnight, the Modified JD (MDJ) was created, which is just $JD-2400000.5$.

By definition the MJD zeroes at solar noon at the 0° meridian. Therefore, it is not a regular time measure, it is tied to Earth's rotation and accelerates or decelerates depending on minute variations of Earth's rotating speed.

You can use basically any solar time including all flavors of UT time to define your MJD, but the most precise is UT1.

But UT1 is not a regular measure of time either, and is also affected by variations on Earth rotation speed. The only really regular time standard among the ones you mention is UTC, which is based on atomic clocks. Being regular, the solar noon drift off UTC and doesn't happen at 12:00 h UTC, therefore, [leap seconds](https://en.wikipedia.org/wiki/Leap_second) are added to keep UTC reasonably close to solar time. But a record of leap seconds is kept so you can use UTC to precisely measure time intervals independently of the variations of Earth's rotation.

In that sense UT1 and UTC are not two flavors of the same thing as you suggest, they actually measure two completely differing things. The first measure Earth's rotation and the second measures time. Due to the same reason, MJD cannot or should not really be referenced to UTC (otherwise it would not zero solar noon).

Said this, in those bulletins the MJD conveys exactly the same information than the date. So "2019 1 2" meaning January 2nd 2019, conveys exactly the same information than MDJ 58485, it is just a more machine friendly way to refer to a specific day. And it also removes the need to account for missing calendar days if you work with dates relatively far in the past.

Now if you want to know how much time have elapsed between two entries in the table, you need to know how to transform whatever version of solar time they use (UT1 in this case), to a regular time reference like UTC or [TAI](https://en.wikipedia.org/wiki/International_Atomic_Time). That's why the "UT1-UTC" value is included. In any case, in doing such calculation you need to take in account any leap seconds added to UTC between the time of the two entries.

Does that makes sense?

> **Comments:**
> **username_0**: Re *Does that make sense?* Yes, it does makes sense, except for one thing, which is that leap seconds always occur on the date when leap seconds are are injected rather than the day after if UT1 was used for MJD. For example, UT1-UTC jumps from -0.557 seconds on 1992/06/30 to +0.443 seconds on 1992/07/31, from -0.408 seconds on 2016/12/31 to +0.591 seconds on 2017/01/01. This is consistent for all points where leap seconds were injected. But since UT1 was behind UTC at midnight on those dates, the value of UT1-UTC should still be negative at those exact dates. But it isn't.  
> **username_0**: Perhaps it's a proleptic UT1? Or perhaps it's UTC, but that makes for a bit of a mess with regard to interpolating pole positions across leap second boundaries.  
> **username_0**: I was being stupid. Since UT1 is behind UTC at a point where a positive leap second is added to UTC, UT1 reaches midnight after UTC does, which means the leap second has already been added to UTC. Thus the shift from a negative UT1-UTC value to a positive value will occur on the day a positive leap second is added to UTC. The change will only show up a day later if a negative leap second is added to UTC. But the odds of that happening are essentially nil given that the Earth's rotation rate is gradually slowing down.  
> **username_1**: Yes. And you shouldn't worry much about that. Just transform the times to UTC, and use those to times for the interpolation. As your data points are spaced every one day, the maximum error in the interpolation will be a fraction of a second, if you worry about that kind of accuracy concerns you can then make an exception for days when a leap second was added.  
> **username_0**: UTC is not uniform; it has leap seconds. That said, a decent (not even great) interpolation algorithm can handle non-uniform abscissae. What I want is a way to determine TAI-UT1 and X and Y pole positions as functions of either UT1 or TAI. I view UTC as something for civilian use only; it was in my opinion a mistake to tie UTC to both UT1 and TAI, and do so at the second level. Doing so has resulted in a significant amount havoc and with a negligible benefit. But that's water under the bridge.  
> **username_1**: @username_0 Absolutely, turning times into TAI and then doing the interpolation removes most complications, the you can bring your interpolated values back to UT1 or UTC.  
> **username_2**: UT1 always has a "day" of 86400 "astronomical seconds", so that the 86400/24:00:00 lapse means one true, complete Earth rotation no matter what. This means are _not_ the same as metric (SI) seconds and vary in length, though a human won't be able to perceive the difference. TAI, and thus UTC, tick metric time, not astronomical time. TAI is a simple, true linear clock (current at 1.942 4867 Gs from its year 1958 epoch as of this posting), UTC though tries to adjust itself so its time-of-day (TOD) value is within 1 s of that of UT1 by adding or removing seconds ("leap seconds").  
> **username_2**: Hence, converting UT1 to TAI is not easy. You need essentially a graph of the length of the astronomical seconds in true metric seconds since the TAI epoch and then you integrate that. And good luck with extrapolation of the scale into the past...  
> **username_2**: IMO we should just "boil the ocean", use TAI as the basis of timekeeping directly (just mod 86400, there you go, there's a time-of-day for civil use, who cares about noon being so precise) and map Earth rotation intervals onto it as a secondary recording for astronomical purposes (what really should be a graph of _angle_ versus _time_.). But meh, we're buried up way past the top of our heads in legacy cruft :g:  

---

### Answer by username_3 on 2019-07-16. Score: 1

Apparently, the IERS publishes values for each 0 h of UTC in their bulletins. I myself thought otherwise, but I recently noticed, in a geodesy exam, that they mentioned UTC for the daily parameters.

Upon closer look at the Bulletins themselves, I was able to confirm this:

[![enter image description here](https://i.sstatic.net/AFVFI.jpg)](https://i.sstatic.net/AFVFI.jpg)

Although using UT1 instead of UTC for interpolation should cause only tiny errors, smaller than the posted errors of the final values.


---

