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

[Evan Ward <evan.ward@nrl.navy.mil>]

Hi Luc,

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.

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

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