Repository navigation
Leap second handling in Time (future-proofing) #350
Description
Time currently uses a SOFA routine that only knows about leap seconds through July 2012. This may need to be updated in a few years.
{{ message }}
Time currently uses a SOFA routine that only knows about leap seconds through July 2012. This may need to be updated in a few years.
Activity
taldcroft commentedon Aug 18, 2012
@astrofrog wrote on astropy-dev:
I wonder if there is a way to use NTP servers to generate tables of
leap seconds? I know it's possible to find out if there is a leap
second announcement via NTP, but I wonder if we can use NTP to
essentially re-generate the leap second table - which would
effectively allow us to abstract away this issue, provided we specify
a number of NTP servers for redundancy.
astrofrog commentedon Aug 18, 2012
Another possibility - allow the user to specify their own list of leap seconds as a last resort? Then we are guaranteed to be able to make old astropy versions work one way or another if a user doesn't have the option to update.
perrygreenfield commentedon Aug 19, 2012
I think a nice way to handle this is to have the library keep a local
table, and that if it it out of date, it checks a server (one we
maintain) for an update. These are only done twice a year usually
(even so, even checking once a month is hardly a burden), so
infrequent checks are necessary. If necessary, we maintain that table
if there is no automatic way of doing it, but one would think there is
an automatic means...
On Aug 18, 2012, at 1:35 PM, Thomas Robitaille wrote:
taldcroft commentedon Aug 19, 2012
@perrygreenfield - sounds good. A related but slightly harder problem is keeping a table of UT1 - UTC offset (or other time scale offsets) up to date. These get updated at least weekly because they depend on the most recent Earth rotation data. It may well make sense to have some sort of internal cron job that fetches new data from available resources and processes into a standard file / URL that astropy.time can expect to be stable. The internal processing layer won't be part of the released astropy and could be updated rapidly in response to external interface changes.
If this seems like the right solution we might want to make some tools so multiple institutions could provide this astropy time service for redundancy. I did see one VO paper about a proposed VO time service, perhaps along similar lines, but I couldn't find anything now that's live (didn't look too hard though).
eteq commentedon Aug 20, 2012
I mentioned this on astropy-dev, but for the local version it makes sense to use the
astropy.config.get_data_*functions, if possible. These currently don't have a way to invalidate the cache after a certain amount of time, but that would be easy to implement if it was needed for this.Also, if we go with @taldcroft's idea of standardizing a format for this info, that's a perfect test case for the data.astropy.org service and associated astropy code (which we have not implemented due to lack of anyone wanting this until now).
embray commentedon Aug 20, 2012
@perrygreenfield Which, incidentally, is exactly the project I have Pritha working on. Not sure when it'll be finished though. I need to spend a little more time guiding her.
To clarify, the way I have her doing it is that if the current date is beyond the next leap second opportunity after the last leap second in the local table, it will attempt to check online for updates. If the the online check fails or is disabled it will issue warnings about possible out of date leap seconds--likewise for dates in the future where the number of leap seconds is unknown (though maybe there's a way to approximate it?)
astrofrog commentedon Oct 9, 2012
Since this is about future-proofing, I'm tagging this as 0.2.0 since it'd be nice to have that code be future-proof.
eteq commentedon Oct 11, 2012
@iguananaut - you mentioned you have someone else working on this - does that mean it can be ready for 0.2 by that person, or does someone else need to do this to get 0.2 ?
Also, as I said above, this would require adding the timed invalidation feature to the cache, which I'm happy to do if it will actually be used here. @demitri also mentioned he may want it for the query-related work
embray commentedon Oct 12, 2012
Hmm we'll see. It's tough because I'm trying to guide the intern through the process, but they haven't been able to come in much lately due to school. This is really two related issues, and I don't know whether there are separate issues for both of them.
For UTC leapseconds we need to get updates from http://maia.usno.navy.mil/ser7/tai-utc.dat; the idea is that if working with a date beyond the last known leapsecond (by at least 6 months), based on user-configured options either:
There's also the question of where to cache these files. Perhaps in ~/.astropy?
Then for UT1-UTC we need to do something similar with IERS bulletin A: http://maia.usno.navy.mil/ser7/ser7.dat using a roughly similar approach.
astrofrog commentedon Oct 13, 2012
@iguananaut - regarding the cache, maybe this should use the
astropy.config.datautilities? (https://github.com/astropy/astropy/blob/master/astropy/config/data.py)eteq commentedon Oct 16, 2012
+1 to @astrofrog suggestion
mhvk commentedon Jan 13, 2015
I cleared the milestone. This could be resolved with the same mechanism, whatever it will be, that we will come up with for automating the IERS A table downloads (#3275).
taldcroft commentedon Mar 2, 2015
Merge pull request astropy#350 from bsipocz/astropy_322