[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Orekit Developers] Extracting TAI-UTC from IERS bulletin A


Evan Ward <evan.ward@nrl.navy.mil> a écrit :


Hi Luc,


Hi Evan,



Based on the feedback you received from the USNO I agree that we should
not use the Bulletin A files for the UTC-TAI. Perhaps we could leave the
new class in Orekit but don't include it in the default loaders. Then if
a user wants to use the UTC-TAI information in the Bulletin A files they
would have to explicitly add the loader.


OK, I have done that and improved the javadoc to make it clear.



I think adding support for the USNO tai-utc.dat files is a great idea
and a feature that I would use.


I have just added it, and taken the opportunity to simplify the
interface for loading UTC-TAI offsets (the older interface has
therefore been deprecated, but I don't think anybody would have
implemented it anyways).

Both UTC-TAI.history and tai-utc.dat are automatically supported
by default, so you only need to have one of these files in your
configuration to get correct dates and avoid the dreaded
"no IERS UTC-TAI history data loaded".

best regards,
Luc



Thanks for finding this issue and running it to ground.

Best Regards,
Evan


On 04/02/2015 06:25 AM, MAISONOBE Luc wrote:

Hi all,

I had recently a request by an operational project to extract TAI-UTC
from bulletin A
files which are already managed by the project rather than extracting
them from
UTC-TAI.history.

I have done it and it is available as a new implementation of the
existing UTCTAILoader
interface. However, I am clearly unhappy with this.

The problem is that there are known issues with TAI-UTC values in some
bulletin A. One
issue was in bulletina-xix-001.txt from 2006-01-05 has a wrong year
for last leap second
and bulletina-xxi-053.tx from 2008-12-31 has an off by one value for
TAI-UTC on MJD 54832).
The Earth Orientation Department at USNO told us this TAI-UTC data was
only provided as a
convenience and this data should rather be sourced from other official
files. They
refered me to bulletin C, but there are also UTC-TAI.history at Paris
observatory or
tai-utc.dat at USNO.

As the bulletin A files are a record of past publications, they cannot
modify archived
bulletins, hence the errors above will remain forever.

The issue from 2008-12-31 seemed to be due to the limit between the
rapid data and the
prediction section being exactly on the day of a leap second
introduction. According to
bulletin A publication schedule, this may well happen again in the
case a leap second
were introduced on 2016-07-01 (which we don't know yet).

Another problem is that bulletin A are not available far in the past
(I could only find back
to 2005) and I am not sure projects that use them keep the full
history, whereas UTC-TAI.history
and tai-utc.dat both preserve all data in one single file.

So I would prefer to remove this feature I just added, and only give
this UTCTAILoader
implementation to this project (the project specifications mandate
this use) and not keep
it within Orekit as it could be misused and is not reliable.

On the other hand, I will probably add support for tai-utc.dat, it is
pretty straightforward.

What to you think?

best regards,
Luc