Update ERFA leap seconds using IERS table.#9334
Update ERFA leap seconds using IERS table.#9334mhvk wants to merge 10 commits intoastropy:masterfrom
Conversation
And rename UpdateLeapSeconds -> SetLeapSeconds.
This also seems to have changed UT1-UTC sufficiently that a doctest had to be adjusted. Sigh.
bcdd5de to
2c8e358
Compare
astropy/utils/iers/iers.py
Outdated
| if no matching leap seconds were found, or if the matches are | ||
| inconsistent. This would normally suggested a currupted | ||
| ERFA or IERS table. The ERFA table can be reset using | ||
| `~astropy._erfa.set_leap_seconds()`. |
There was a problem hiding this comment.
| `~astropy._erfa.set_leap_seconds()`. | |
| ``astropy._erfa.set_leap_seconds()``. |
as _erfa is not part of the public API I think.
There was a problem hiding this comment.
That is a good point. Given that, maybe it is better to include an explicit way to reset the table inside iers.
There was a problem hiding this comment.
I now changed the method so that it takes an argument that allows one to initialize the table (and also so that it returns the final one).
2c8e358 to
7c54a24
Compare
| ^^^^^^^^^^^^^ | ||
|
|
||
| - Leap seconds are now automatically inferred from IERS tables, ensuring that | ||
| in normal usage they will not be out of date even if astropy and erfa are |
There was a problem hiding this comment.
When does "normal usage" check for new versions of the leap seconds table? When it's been six months since the last bulletin C? When a time is encountered that is more than six months since the last Bulletin C? When someone needs IERS A data for some other non-leap-second purpose?
| auto_max_age = _config.ConfigItem( | ||
| 30.0, | ||
| 'Maximum age (days) of predictive data before auto-downloading. Default is 30.') | ||
| 'Maximum age (days) of predictive data before auto-downloading. Dfault is 30.') |
There was a problem hiding this comment.
Sometimes I wonder about myself... Thanks, will correct.
|
@aarchiba - taking this out of the in-line comments, since it is important: indeed, with the current scheme the light seconds get updated only when an IERS table is opened. And, now that you mention it, this is probably not good enough - we need the leap seconds for TAI-UTC, but the IERS tables are opened only for UT1 and coordinate transforms. I think we probably need instead to check any time the TAI<->UTC transformation is done (if the time requested is more than 6 months beyond the last leap second / the last time it is checked. Arguably, that means we should start down-loading bulletin C and give up on the approach here. @eteq - what do you think? p.s. It would be good to at least get the C integration merged. |
It doesn't look like Bulletin C contains information about past leap seconds (except in historical bulletins), so one needs an up-to-date data file of some kind. Unfortunately IERS A is kind of big. Does IERS B contain leap second information? It would seem that being aware of the end of validity of the leap second table currently in use is valuable, as well as some way to update it, even if it is not totally clear yet how best to obtain the information needed to update it.
Definitely. Is C needed to be able to obtain the last time we know there are no leap seconds? |
|
@aarchiba - I'm about to push a different version where IERS C is used (more specifically, the whole set, which includes an expiration date). |
|
closing in favour of #9365 |
Step 2, following up on #9329, now letting the IERS table update ERFA's leap seconds whenever they are opened. Not 100% sure about the implementation (or the naming), but certainly something to look at.