Fix buggy time conversion code

[aarchiba]

Update: essentially all precision problems intrinsic to PINT are under control at the nanosecond level or better, as far as I know and hypothesis can find. The remaining xfail tests are almost all pointing out upstream problems, whether due to astropy bugs or ERFA limitations. The astropy bugs are fixed in the current 3.2.2 release and should be fixed in the final 2.0.16 release which will appear in a few months. (2.0.15 was meant to be the final if-theres-a-bug-tough-luck python2 release but in light of the bug revealed here and other worries the mainainers decided to delay stopping bug fixes.)

The patch also dramatically simplifies the precision-conversion functions in pint.utils by providing new astropy.time.Time formats mjd_string and pulsar_mjd_string that read and write full-precision strings, as well as mjd_long and pulsar_mjd_long that write but do not read long doubles (reading long doubles is prevented by a frustrating limitation of astropy, under discussion for removal in astropy 4). Conversion of existing code to replace time_to_* and time_from_* with the new formats has not been carried out yet.

Was:

We have a number of severe time conversion problems, producing errors of, in some cases, 60s or a day. Others may just be off by a microsecond. I am fixing them where I can but there are a number I have not tracked down yet. This PR tracks those with xfail statements; use

pytest --runxfail -v tests/test_precision.py

to see the damage.

Most but not all of the problems center around days with leap seconds, and some of the problems appear to originate from within our pulsar_mjd implementation (possibly but I hope not from within ERFA).

[scottransom]

@aarchiba So do you think this is a SOFA/ERFA bug? Since I'm on the SOFA board, if you can give me a simply example of the numerical issues, it will get fixed. We just did that over the last year for another small issue or two.

[aarchiba]

I'm not totally sure whether I'm interpreting the ERFA output correctly, but if you want I can put together some tests that give astropy._erfa some significant exercise and report any bugs I come up with. Translating them back into C to be sure they're really SOFA bugs and not somewhere in the wrappers would be... more work.

Is there documentation of the level of accuracy I should expect from various ERFA/SOFA routines, over what range of inputs?

[scottransom]

There is a lot of SOFA documentation. And given that the times are stored internally with two doubles, the intent is to have very high precision where possible -- certainly much better than a microsecond. I'd have to dig around to see what is expected overall. But if there are definite instabilities at the ns level -- especially if they can be fixed easily, then those should definitely be fixed.

[aarchiba]

Okay, well, a quick check shows that a roundtrip through d2tf and tf2d gives nanosecond accuracy for ndp=9 but does not give nanosecond, or even ten-nanosecond, accuracy for higher ndp. No errors or warnings are emitted. See 3cc6a8a.

[aarchiba]

Travis has gotten grumpy again. Even apt-get is failing to pull stuff across the network. At least it's usually fairly obvious (! instead of x next to runs).

[aarchiba]

TODOs:

• mjd_decimal and pulsar_mjd_decimal
• day_frac_longdouble? Does day_frac work for longdoubles?
• can't get rid of time_from_longdouble, but maybe use day_frac_longdouble?
• TimeDelta formats "mjd_long", "mjd_decimal", and "mjd_string"; need care as they could be used on nanoseconds up to decades

DONEs:

• Convert code base to eliminate time_to functions
• Get rid of time_from_mjd_string

There are other places precision could be mishandled - Parameters that are supposed to handle long doubles spring to mind - but I think that this is enough for one patch.