search

aewallin / allantools

Allan deviation and related time & frequency statistics library in Python
GNU Lesser General Public License v3.0
226 stars 77 forks source link

Include datetime functions in allantools? #87

Closed aewallin closed 8 months ago

aewallin commented 5 years ago

Many times we require conversion of time-stamps from one format to another.

I have been using some versions of "gpstime" and "jdutil" for GPS-timescale and Modified Julian Date conversions. gps-functions e.g. there: https://github.com/aewallin/ppp-tools/blob/master/gpstime.py JD/MJD functions e.g. there: https://gist.github.com/jiffyclub/1294443 or there: https://github.com/aewallin/ppp-tools/blob/master/jdutil.py

These could be included in allantools, perhaps as an extended subclass of datetime.

aewallin commented 5 years ago

see also: https://arrow.readthedocs.io/en/latest/

fmeynadier commented 5 years ago

I always hesitate for this kind of things... Here are my thoughts, sorry for the rant:

Astropy has a astropy.time module that provides a full-fledged converter between various timescales. It relies on "ERFA", an authorized fork of SOFA that is wrappable in python scripts, (SOFA being the reference implementation (in C and fortran) provided by IAU for timescales and reference systems transformation. When a leap second is introduced, SOFA is updated, so leap seconds are always taken correctly in account when your SOFA routines are up-to-date.

I like the way astropy.time separates timescales and representation, and its very large panel of possible transformations. I also like the fact that it is maintained by a large community, and not me ! (caveat: 2018-01-30 SOFA version does not seem to be ported yet into the ERFA repository, maybe updates have stalled... Not a major issue as long as no new leap second is introduced, yet worrying for the future, but you see that the update path for leap seconds has lots of layers...).

On the other hand astropy is quite a large dependency, largely overkill for allantools needs. (Its loading time makes it not practical either for frequent interactive usage, e.g. the "mjd" command we probably all have in our path, compiled from a decades-old piece of fortran or C, transmitted from colleague to colleague since cardboards...).

When I don't want to import astropy and need a lightweight function I just forget about pre-1582 dates, and even throw an exception for dates before 17th Nov, 1858, so MJD is just a positive datetime.timedelta as long as there is no leap second in the dataset: it barely needs a dedicated function.

Back to the particular case of allantools: I agree it would be nice to have these conversion functions available, but if we want to do it properly we would need some mechanism for leap seconds updates, and I think it would almost make a case for a distinct package. The "arrow" package you link to is interesting but, unless I missed something, would also need some additional code to handle the timescales we are interested in, am I wrong ? In the end, if we have to implement automatic updates for leap-seconds and add some code for unsupported timescales, why not use astropy.time directly ?

aewallin commented 5 years ago

Thanks for the detailed comments! I agree that we leave datetime functions out of allantools for now - there is enough work already to maintain the current code. Before closing this issue it would be good to summarize this discussion, and the alternative libraries like astropy/arrow, in the documentation - perhaps a short description in the front-page readme.