Repository navigation
IERS warning during astropy.coordinates for dates that should be covered by IERS data #10219
Description
The following code emits a couple of warnings related to the IERS data validity:
In [26]: from astropy.coordinates import ICRS, EarthLocation
In [27]: from astropy.time import Time
In [28]: EarthLocation.from_geodetic(0, 10).get_itrs(Time('2019-03-04', scale='utc')).transform_to(ICRS)
WARNING: Tried to get polar motions for times after IERS data is valid. Defaulting to polar motion from the 50-yr mean for those. This may affect precision at the 10s of arcsec level [astropy.coordinates.builtin_frames.utils]
WARNING: (some) times are outside of range covered by IERS table. Assuming UT1-UTC=0 for coordinate transformations. [astropy.coordinates.builtin_frames.utils]
Out[28]:
<ICRS Coordinate: (ra, dec, distance) in (deg, deg, m)
(163.82934208, 6.88151907, 1.48836291e+11)>However, the current IERS data in astropy is from the bulletin issues January 2020, so shouldn't any date before January 2020 be considered valid, even if it comes after the latest leap second? In other words, should we have a way of specifying the range of validity and not rely simply on the first/last leap second?
Activity
pllim commentedon Apr 28, 2020
cc @eteq and @mhvk
mhvk commentedon Apr 28, 2020
Weird, when I do the same thing:
So, it is downloading a new file... (this is on current master, which includes @eteq's change in IERS server - #9964)
mhvk commentedon Apr 29, 2020
Coming back to this, what is weird is that the table packaged with astropy stops at
2017 11 12, while the leap second file is up to date. @bsipocz - is the scriptupdate_builtin_iers.shnot working?bsipocz commentedon Apr 29, 2020
@mhvk - apparently the instruction about the iers update got added to the release docs before 4.0.1, but I forgot to run the script for that release. Otherwise it seems to be working if I run it now. Do you want a PR now, or closer to the release?
mhvk commentedon Apr 29, 2020
@bsipocz - Ah, no worries! Let's do it right before release.
pllim commentedon Apr 29, 2020
I milestoned this issue to 4.1 as a reminder that this should be resolved with the release, so we can close it after.
bsipocz commentedon Apr 29, 2020
Oh, our past selves thought about this: #9018
Anyway, I need to get into the routine to update them for the bugfix releases as well, so the more it comes up the better chances. (Since so many things changed in the release procedure for 4.1, I'll certainly use the docs for that one :) )
astrofrog commentedon Apr 29, 2020
Maybe we should have the bot automatically open a PR every time a leap second is added!
bsipocz commentedon Apr 29, 2020
Either that, or even if just keeping a bot eye on the bundled packages and files and opening an issue as a reminder that updated versions are out. cfitsio, wcslib and the leap seconds to begin with.
mhvk commentedon Apr 29, 2020
The leap second tables are released very regularly (even if there is no leap second, just to change the expiry date), so I think that is automatable. Indeed, perhaps the bot can subscribe to IERS bulletin C... (or likely more easily, check that the bundled version is up to date with the remote one).
bsipocz commentedon Apr 29, 2020
if either of these have an RSS feed, the simplest is to sign up on the feed for a slack channel (what we already do to monitor pytest and sphinx releases)
pllim commentedon Apr 30, 2020
I don't see any RSS option listed on that page, unfortunately, but I might have missed it.
mhvk commentedon Apr 30, 2020
We could also check
astropy.utils.iers.IERS_LEAP_SECOND_URL...EDIT: Added link to code
astropy/astropy/utils/iers/iers.py
Line 59 in 60ab27c
mhvk commentedon May 3, 2020
Removed milestone and "last before release" as the critical aspects are covered by #9018. This one here can now be just about how to automate the updates.
ayshih commentedon Mar 12, 2024
Presumably moot with
astropy-iers-data(#14819)?mhvk commentedon Mar 12, 2024
Agree, the automation is solved.