6
$\begingroup$

IERS Bulletin A and Bulletin B 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.

Improve this question
$\endgroup$

2 Answers 2

Reset to default
3
$\begingroup$

Short answer: UT1

Long answer:

The 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 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. 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?

Improve this answer
$\endgroup$
9
  • 1
    $\begingroup$ 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. $\endgroup$
    – David Hammen
    Mar 16, 2019 at 2:18
  • $\begingroup$ 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. $\endgroup$
    – David Hammen
    Mar 16, 2019 at 2:21
  • 1
    $\begingroup$ 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. $\endgroup$
    – David Hammen
    Mar 16, 2019 at 9:07
  • $\begingroup$ 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. $\endgroup$
    – Camilo Rada
    Mar 16, 2019 at 17:13
  • $\begingroup$ 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. $\endgroup$
    – David Hammen
    Mar 16, 2019 at 17:57
1
$\begingroup$

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

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

Improve this answer
$\endgroup$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.