Update IERS_B file and adjust to new-style - #14382

Thank you for your contribution to Astropy! 🌌 This checklist is meant to remind the package maintainers who will review this pull request of some common things to look for.

• Do the proposed changes actually accomplish desired goals?
• Do the proposed changes follow the Astropy coding guidelines?
• Are tests added/updated as required? If so, do they follow the Astropy testing guidelines?
• Are docs added/updated as required? If so, do they follow the Astropy documentation guidelines?
• Is rebase and/or squash necessary? If so, please provide the author with appropriate instructions. Also see "When to rebase and squash commits".
• Did the CI pass? If no, are the failures related? If you need to run daily and weekly cron jobs as part of the PR, please apply the "Extra CI" label. Codestyle issues can be fixed by the bot.
• Is a change log needed? If yes, did the change log check pass? If no, add the "no-changelog-entry-needed" label. If this is a manual backport, use the "skip-changelog-checks" label unless special changelog handling is necessary.
• Is this a big PR that makes a "What's new?" entry worthwhile and if so, is (1) a "what's new" entry included in this PR and (2) the "whatsnew-needed" label applied?
• Is a milestone set? Milestone must be set but we cannot check for it on Actions; do not let the green checkmark fool you.
• At the time of adding the milestone, if the milestone set requires a backport to release branch(es), apply the appropriate "backport-X.Y.x" label(s) before merge.

Would probably need quick bugfix releases after this is merged? cc @astropy/astropy-project-release-team

I guess users should not generally run into this, since we include the IERS_B file in the release, but given that there seems to be a big group in the wild which is affected, a quick bugfix release might still be called for.

Failures look related. I wasn't expecting changes... did they change the format and the actual data?

Weird failures indeed! Checking the UT1-UTC one for 2010:001:

# old data
      Date      MJD      x          y        UT1-UTC       LOD         dX        dY        x Err     y Err   UT1-UTC Err  LOD Err     dX Err       dY Err  
2010   1   1  55197   0.098695   0.192853   0.1140330   0.0005515   0.000102  -0.000071   0.000082   0.000061  0.0000304  0.0000133    0.000046    0.000049

# new data
# YR  MM  DD  HH       MJD        x(")        y(")  UT1-UTC(s)       dX(")      dY(")       xrt(")      yrt(")      LOD(s)        x Er        y Er  UT1-UTC Er      dX Er       dY Er       xrt Er      yrt Er      LOD Er
2010   1   1   0  55197.00    0.098670    0.192840   0.1141359    0.000195    0.000054   -0.001976    0.000512   0.0005004    0.000068    0.000053   0.0000598    0.000077    0.000093    0.000081    0.000118   0.0000628

This is not the first time the "historical" data have changed -- I think they re-analyze once in a while.

I think here we would just need to update the tests, but I'd prefer not to backport that, but rather have it only appear in 5.3. So, in #14384 we just update the IERS_B_URL for backporting, and then for 5.3 we can do this.

Converted to draft so we do not merge this before #14384 is done.

#14384 is merged.

OK, I rebased and tried to make all the small changes that are required because the IERS B numbers have changed.

I don't think this is a bug fix anymore. Move change log fragment to "API change"?

"It looks ok," Christian Bizouard (Observatoire de Paris / SYRTE)

Needs a rebase with the partial revert merged. Thanks!

Rebased. Also tried to rename the changelog fragment to 14382.other.rst but pre-commit complained about that -- it can only be done in the root directory (for reasons a bit beyond me). Anyway, decided to go with "feature" since we now support the new IERS B format/analysis.

"other" is only acceptable if it is not inside a subpackage folder, I think.

EDIT: Yup, see https://github.com/astropy/astropy/blob/main/docs/changes/README.rst

In case you haven't seen the memo, here it is:

************************************************************************
IERS Message No. 471                                   February 01, 2023
************************************************************************


Implementation of the IERS 2020 C04 system on 14 February 2023


The IERS will be implementing the 2020 International Terrestrial
Reference Frame (ITRF2020) and making it available in its EOP products
on 14 February 2023. The official IERS 20 C04 final solution will be
available in the usual repertory:

https://hpiers.obspm.fr/iers/eop/eopc04/

(Short description:
https://hpiers.obspm.fr/iers/eop/eopc04_20/eopc04.txt)

The Rapid Service/Prediction Center solution will be available at
https://maia.usno.navy.mil/ser7.

In addition to the alignment with ITRF2020, the C04 series present a
new format given in a shortened header, and include pole rates. The
former version will be produced until June 2023 and put in the repertory
https://hpiers.obspm.fr/iers/eop/eopc04_14/. The yearly series will be
suppressed.

Users are advised to update their data from these sites on 14 February
to ensure that they are fully consistent with the new 20 C04 system. Any
data appearing on these sites before that date should be considered
preliminary.

C. Bizouard, IERS Earth Orientation Center, Paris Observatory
N. Stamatakos, IERS Rapid Service/Prediction Center,
US Naval Observatory


************************************************************************
IERS Messages are edited and distributed by the IERS Central Bureau.
If not stated otherwise, the IERS is only the distributor of the message
and is not responsible for its content.
To submit texts for distribution, please write to
<[email protected]>.
To subscribe or unsubscribe, please create an IERS account or modify it:
https://www.iers.org/Login/Login/EN/login_node.html
or write to <[email protected]>.
Archives: http://www.iers.org/IERS/Messages
************************************************************************

This isn't IERS Bulletin B, btw. That is just preliminary monthly data. This is the final data except for the last 30 days, which gets an updated solution twice a week. My go to site for all of this is:
https://www.iers.org/IERS/EN/DataProducts/EarthOrientationData/eop.html

Thanks for posting that! And, indeed, it isn't really IERS B, but well, at the time it seemed it was to me... (though the series that we actually download is not as "final" as you suggest or I thought; we've seen quite large parts changed, even if just by minimal amounts, of course, well within errors).

That's interesting as the documentation says that only the last 30 days gets updated. C04.guide.pdf

Yes, it is weird. See, e.g., #10376

But more importantly, @mkbrewer, does it make sense to you to shift to the new format with the new IRTF, and adjust tests accordingly? I guess the e-mail you quoted suggests we may not have much choice, though I think they have moved some things back because we contacted them (and perhaps others too). Mostly wondering if somewhere else we implicitly assume some version of the IRTF.

Astropy doesn't assume anything about the ITRF. The IERS has just updated the frame is all. So, yes we need to adopt the new frame and adjust the tests accordingly.

Can we push this forward or does this need more discussion/changes? Thanks!

After @mkbrewer's confirmation that this is OK, I think we can just go ahead and merge!