Possible improvements to how IERS is handled

In #9204, @aarchiba wrote a comment that deserves to be its own issue:

Thinking about user desires:

• User wants a specific IERS A table, or IERS B table, or merged version, for reproducibility.
• User wants some kind of IERS data and has no connectivity.
• User wants an IERS A or B table that covers all the data in some particular data set.
• User wants the best available data that covers their data set.
• User wants IERS data to “just work” for reasonable times, past present and near future.
• User doesn’t actually care much about accuracy but needs a stable set of IERS data for simulations possibly extending quite far into the future. (Observation planning, or generating par files for future observations of the triple system, for example.)
• User wants all astropy things that use IERS tables to use the same set of tables, whether autoupdated or not: having old the IERS data change partway through a computation because you requested an observatory position past the end of the cached table is liable to lead to some hair-tearing bugs that affect scientific results.

I’d like to see:

• A way to merge specific IERS A and IERS B tables to get a best-available combination.
• A way to get up-to-date-enough IERS A and IERS B tables (PINT needs IERS B specifically to agree with TEMPO2), preferably without user effort beyond perhaps making one request for all times up front.
• A way to have a “best-effort” IERS table - if the network is up, a merged version of auto-updated IERS A and B. Graceful degradation through the most recent A and B tables that exist in the cache to the plain B table distributed with astropy if the network is not available.
• A way to tell astropy to use specific table versions for either everything, or just everything inside this with block.

These four seem to cover all the use cases that sprang to my mind. Only the last, the context management, seems tricky to me, and that only if multithreading is to work right.

I think we can get quite a bit on the way by:

• Having the IERS file used throughout astropy be a ScienceState object (see #9244);
• Extending auto-update to IERS-B (i.e., maybe have IERS_A_Auto and IERS_B_Auto classes); (see #3961 for general caching issues…)
• Use #8981
• Allow explicit merging of two IERS-B and IERS-A files.
• (edit) Does this still belong in utils? astropy.iers might be more logical
• What about #9479 ?
• What about #10219 ?

[bjweiner]

Hi, I understand that there are some complex issues here and that one does not want to design the IERS module so as to rule out future development of improved IERS tables, tracking for reproducibility, and so on. However, I want to raise a more basic design issue (I think). astropy.iers is frequently called by other astropy (or astroplan) modules. Many, I’d guess most, astropy “users” do not call iers themselves. So when iers throws an error, the user cannot easily fix it by trapping it in user code. (See https://github.com/astropy/astropy/issues/12998 for an example where I had to patch astropy.time to bypass the latest IERS outage and astropy.iers error.) Because astropy.iers failures result in a fundamental inability to tell the time, this affects critical systems even if they don’t need high precision.

I want to advocate that astropy.iers should default to a “Just Work” behavior that is robust and can always return at least a low precision value and a warning, regardless of network outages, rather than throwing an error. While users who need to insure the highest accuracy or extra measures to insure reproducibility would set this behavior by some optional variable.

[pllim]

Actually, they are configurable:

https://github.com/astropy/astropy/blob/910f2f713cbf4d3476c83f6ad6bd9ac96c20378b/astropy/utils/iers/iers.py#L126-L131

But as @weaverba137 mentioned above, the trick is to get all that to kick in before some internal import tries to access the leap seconds table.

Maybe try setting it in your ~/.astropy/config/astropy.cfg? See https://docs.astropy.org/en/stable/config/index.html