All,
I have come across a bug (I just didn't know it at the time), and per Luc's suggestion, will share it with the mailing list.
In upgrading from 6.0 from 5.0.3 the time scale of AbsoluteDate.JAVA_EPOCH changed from Terrestrial Time (TT). The doc on this field states UTC and TAI are equivalent before 1972, but per the explanation below, that changed with the introduction of the Linear Offset of UCT to TAI in a later code commit.
When running a simple test as follows:
public static void main(String[] args) {
AbsoluteDate epoch = AbsoluteDate.JAVA_EPOCH;
System.out.println(epoch.toString(TimeScalesFactory.getTAI()));
System.out.println(epoch.JAVA_EPOCH.toString());
//Milliseconds - April 1, 2006
long msOffset = 1143849600000l;
AbsoluteDate ad;
try {
ad = new AbsoluteDate(epoch, msOffset/1000, TimeScalesFactory.getUTC());
System.out.println(ad);
} catch (OrekitException e) {
e.printStackTrace();
}
AbsoluteDate ad_2 = new AbsoluteDate(epoch, msOffset/1000, TimeScalesFactory.getTAI());
System.out.println(ad_2);
}
I received this as the output:
1970-01-01T00:00:00.000
1969-12-31T23:59:52.000
2006-03-31T23:59:52.000
2006-03-31T23:59:27.000
The final result seems appropriate given the offset between UTC and TAI in 2006 was 33 seconds, however the 8 second shift had me baffled, it is a result of the Linear model present prior to Jan 1 1972.
1966 Jan. 1 - 1968 Feb. 1 4.313 170 0s + (MJD - 39 126) x 0.002 592s
1968 Feb. 1 - 1972 Jan. 1 4.213 170 0s + ""
This works out to 8.000082, assuming an MJD of 40587 (1970-01-01),rounding to the Millisecond fidelity and its 8 seconds flat.
I was able to find a workaround for this by building a new Java_Epoch from the Date/Time Components as follows:
AbsoluteDate java_epoch = new AbsoluteDate(DateComponents.JAVA_EPOCH, TimeComponents.H00, TimeScalesFactory.getUTC());
AbsoluteDate ad = new AbsoluteDate(java_epoch, offset, TimeScalesFactory.getUTC());
Luc's Response
Hi Matt,
Note that this type of questions would be more appropriate on the users
list than by direct mail. It would allow other people to see it.
>
> I have completed a bit more digging on this, and have discovered where
> the 8 seconds off-set come from.
>
> The UTC-TAI.history file states:
> 1966 Jan. 1 - 1968 Feb. 1 4.313 170 0s + (MJD - 39 126) x 0.002 592s
> 1968 Feb. 1 - 1972 Jan. 1 4.213 170 0s + ""
>
> This works out to 8.000082, assuming an MJD of 40587
> (1970-01-01),rounding to the Millisecond fidelity and its 8 seconds flat.
You are right.
The comment stating that UTC and TAI were equal prior to 1972 was added
on 2010-10-06, as part of commit 3098823c (see
<
https://www.orekit.org/forge/projects/orekit/repository/revisions/3098823c4caab03227a5106aa488a5457ffcf61d>).
However, a few days later, on 2010-10-11, another change was introduced
with commit e8421aa, and the lineart models for UTC-TAI between 1961 and
1972 were supported after this change. You can see the change here:
<
https://www.orekit.org/forge/projects/orekit/repository/revisions/e8421aad7e74b212e523b43d7f63a3f736e460e7>,
and in particular the UTCScale.java file. Note that as some people don't
use the IERS UTC-TAI.history file but rather their own files with only
the leap seconds without the linear models, these linear models are not
parsed, they are directly hard-coded in the library so you will get them
regardless of the files you use.
This later change invalidated the comment for JAVA_EPOCH, but I did not
notice it. You have found a bug!
Could you file this bug on the forge using
<
https://www.orekit.org/forge/projects/orekit/issues>? You will have to
register to the forge in order to be able to file a new issue.
>
> I was also able to get my code working again by building an absolute
> date from the Date/Time Components, rather than using the Static one
> inside AbsoluteDate
>
> AbsoluteDate java_epoch = new AbsoluteDate(DateComponents.JAVA_EPOCH,
> TimeComponents.H00, UTCScaleHelper.getUTCScale());
> AbsoluteDate ad = new AbsoluteDate(java_epoch, offset,
> TimeScalesFactory.getUTC());
>
> I am not sure if this is the preferred solution or if I am off-base, but
> it does do the trick. I would still love to hear if you have some
> insight into the original email, and the JAVA_EPOCH from AbsoluteDate.java
I should fix the JAVA epoch. Once it is fixed, you would only need the
second statement defining "ad" as an offset from AbsoluteDate.JAVA_EPOCH.
best regards,
Luc
------
Thanks Luc, I appreciate your well thought out and thorough responses. They help immensely.