Even if IERS_Auto predictive values are stale, do not download IERS-A if downloading is disabled - #17387
Conversation
|
👋 Thank you for your draft pull request! Do you know that you can use |
efe45d8 to
0dd14c5
Compare
e2c3406 to
2b02f84
Compare
|
Even though this test fixes the bug that prompted #17359, it does not mean that #17377 can be reverted, because we still need those tests to pass even when interpolating off of stale IERS_Auto predictive values. Setting |
neutrinoceros
left a comment
There was a problem hiding this comment.
LGTM. Anything else you wanted to do before undrafting ?
|
To really test this, do we have to undo the setting added in #17377 ? |
2b02f84 to
f01dca7
Compare
|
@pllim I'm confused about milestoning here: shouldn't this go to 7.0.0 ? |
Just added a bit of polish to the test and comment.
Nope, this bugfix is tested by the additional test in this PR. The coordinate tests fixed by #17377 still need to be fixed in that fashion, with their purpose to test coordinates code, not IERS code.
Yes, please put this in 7.0 if possible. |
|
I'll enable auto-merge. I don't think 7.0.0 is possible anymore, unless the release team decides to rebranch it from 7.0.x. |
…ale, do not download IERS-A if downloading is disabled
|
Milestone during RC period is confusing for me as well. Not sure where @saimn is going to tag for release if we are not doing RC2. |
…387-on-v7.0.x Backport PR #17387 on branch v7.0.x (Even if IERS_Auto predictive values are stale, do not download IERS-A if downloading is disabled)

This PR fixes the root bug revealed by #17359: the code that identifies stale IERS_Auto predictive values would always try to download a more up-to-date IERS-A even if downloading was disabled (
auto_download=False).This bug was essentially introduced by #16187, because previously
auto_download=Falsewould ignore the bundled IERS-A entirely, stale or not.