You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Upcoming leapsecond updates for older releases #3791
There will be a new leap second on 2015-06-30. How will astropy deal with this? If I understand correctly, for new releases/pulls from git the newer IERS tables will be included. Is that correct? If so, any idea when (the IERS A file already includes the new leap second)?
More importantly, is there a way to properly update those files for older releases? Some people hesitate to upgrade critical installations (used by large processing efforts) but we don't want times to get out of sync. I see:
@dlakaplan - note that the IERS tables only affect UTC->UT1, not the leap seconds in, e.g., UTC->TAI. It does mean that both IERS and ERFA(?) needs to be updated. CC @taldcroft. And cc @eteq as the one who thought he could make a nice automatic script. Also see #3275.
The current master for the ERFA project has the leap second in it (thanks to @timj with liberfa/erfa#26).
So we need:
A release of ERFA (v1.2?)
Incorporate the ERFA 1.2 into astropy.
A bugfix release of astropy.
Now here is where it gets interesting. We want to get this into an astropy release soon, and definitely well before June 30. That means a bugfix / patch release. I think that the update to ERFA can be mostly classified (at least for our purposes) as a bugfix release, though it does appear some "duplicate" functions were removed. I haven't dug into exactly what that means.
I think just copying the dat.c to an older release is all that is needed. That file doesn't care about any other part of ERFA. Regarding the duplication -- I think that was because a header file had declared the same function twice.
I think in the past I've said that if we want to release leapsecond updates we can do it as patch releases. I agree it should be backported to 0.4.x as well.
Activity
dlakaplan commentedon May 21, 2015
Sorry, I meant:
mhvk commentedon May 21, 2015
@dlakaplan - note that the IERS tables only affect UTC->UT1, not the leap seconds in, e.g., UTC->TAI. It does mean that both IERS and ERFA(?) needs to be updated. CC @taldcroft. And cc @eteq as the one who thought he could make a nice automatic script. Also see #3275.
taldcroft commentedon May 21, 2015
The current master for the ERFA project has the leap second in it (thanks to @timj with liberfa/erfa#26).
So we need:
Now here is where it gets interesting. We want to get this into an astropy release soon, and definitely well before June 30. That means a bugfix / patch release. I think that the update to ERFA can be mostly classified (at least for our purposes) as a bugfix release, though it does appear some "duplicate" functions were removed. I haven't dug into exactly what that means.
@eteq @timj - thoughts?
As @dlakaplan notes it would be nice to backport the leap second update to at least 0.4.x. Can that be done simply by a change to
dat.clike here?taldcroft commentedon May 21, 2015
Oops, I meant to cc @embray on this for comment about a bugfix release.
timj commentedon May 21, 2015
I think just copying the
dat.cto an older release is all that is needed. That file doesn't care about any other part of ERFA. Regarding the duplication -- I think that was because a header file had declared the same function twice.embray commentedon May 22, 2015
I think in the past I've said that if we want to release leapsecond updates we can do it as patch releases. I agree it should be backported to 0.4.x as well.
eteq commentedon May 28, 2015
I think we could possibly have considered this closed by #3794, but definitely #3802 should do the job.
embray commentedon May 29, 2015
Yup, this is ready to go.