Repository navigation
Automatic download of IERS A table for times not covered by IERS B #3275
Description
It has turned out to be very confusing to users (and us!) that Time cannot calculate the sidereal time for times around now or in the near future. For this purpose, the IERS A table can be used with some handy-work [1], but this could and probably should be automated. One question is the extent to which this should be completely automatic -- the file is not exactly small. Another question is what should happen for times further in the future. Possibly sidereal_time at least could have an option sloppy=True where future leap seconds and earth rotation are ignored.
[1] http://docs.astropy.org/en/latest/time/index.html#transformation-offsets
Activity
mhvk commentedon Nov 2, 2015
Some implementation comments: #3274 (comment)
This would be very important. Neither @taldcroft nor @mhvk feels qualified to do this.
mhvk commentedon Nov 2, 2015
The same mechanism could be used for leap seconds (#350), though that is covered generally by erfa updates (but that requires people to be good about point releases).
See in particular #350 (comment)
eteq commentedon Dec 16, 2015
A relevant mailing list exchange:
taldcroft commentedon Dec 17, 2015
As mentioned we're looking for volunteers. But if nobody steps up in the next month or two I will put this on my plate for astropy 1.2 and see if I can put together something that fills this need.
embray commentedon Dec 21, 2015
This aspect would be solved for free if someone worked on #3961. If there are aspects to this specific to IERA data that can be worked on separately, or solved easily in the near term that's fine too. But in general if you want the cache to be updated when it's appropriate to do so #3961 is your answer, not an ad-hoc expiration time.
taldcroft commentedon Dec 31, 2015
@mhvk - I'm having a look at this. I do not have the time or inclination to do #3961, but I think that our problem is much simpler because we have prior knowledge of update cycle for the bulletins.
My first question is more basic: can we just use IERS-A always? I don't have a full understanding of everything in the A and B bulletins, but it appears that A is a superset of B (at least for how it gets used in astropy). In particular the fact that the B values for UT1_UTC, PM_X, and PM_Y are included in A seems good. If we could always use IERS-A then that would allow significant simplification and take away this distinction which is confusing for non-experts.
taldcroft commentedon Dec 31, 2015
OK, I do now see that the B values start in 1962 vs the A values in 1973. That could be easily handled in a way that is transparent to users.
mhvk commentedon Jan 4, 2016
@taldcroft - I think using IERS B values from the IERS A bulletins should be fine (although, annoyingly, I don't think they have the same number of significant digits; I recall finding that, therefore, entries were not strictly identical). The main reason I stuck to IERS B is that I wanted to ensure that by default, one either got a reproducible result or none at all, i.e., I wanted to avoid using predictions without explicit opt-in from the user. Obviously, though, even with IERS A tables, things could be set up to behave that way. Still, my sense would be for our releases to keep providing IERS B, as the one formally approved.
Overall, I remain a bit torn about the approach. On the one hand, I think you are right that our case is at least partially independent of specific caching mechanisms. Essentially, we have:
time < iers['MJD'][-1], use current version.This suggests one could one could start with getting 2. to work.
On the other hand, from a quick look at #3961, it does seem that, really, astropy should just use
CacheControl(replacing its own caching mechanism, which I think you have been finding to be somewhat less than robust anyway...) and this would quite trivially solve the present issue.