Make cftime.datetime - cftime.datetime -> timedelta microsecond-exact#178
Make cftime.datetime - cftime.datetime -> timedelta microsecond-exact#178jswhit merged 4 commits intoUnidata:masterfrom
Conversation
|
Wow - very simple and elegant solution! I can merge once you resolve the conflicts. |
|
Thanks @jswhit -- indeed I was pleasantly surprised to find that I could reuse the Merge conflicts have been resolved; I think things should be ready to go. |
|
Merging now. I will wait a week or so and then push another release. |
|
Oops - we forgot the Changelog entry. @spencerkclark - can you create another PR with an updated Changelog for this and PR #176? |
|
Also, it would be good to run the xarray test suite to make sure this has not broken anything before a new release |
Ah yes, thanks for reminding me -- see #179.
Yes, I've confirmed that the xarray test suite passes with the latest updates. I'm looking forward to eventually being able to remove some of the tolerance logic we have in our cftime round-tripping tests (we'll still support older versions of cftime for some time). |
Currently subtracting a date from another to produce a timedelta is not microsecond-exact:
I think this is actually pretty straightforward to fix using some code that already exists in cftime. I'm drawing inspiration here from the way this kind of operation is done in Python's datetime object. As I understand it, we can simply use
_IntJulianDayFromDateas something essentially equivalent todatetime.datetime.toordinal, and everything else should basically be the same.The test confirms the example above is fixed for all calendars, and all other existing tests of timedelta arithmetic pass. @jswhit I think this should enable the exact version of
date2numyou described in #171 (comment). I could try to add that here or in another PR. As you note, it would be awesome to be able to round-trip dates without loss of precision.xref: #109 (this would make the function described there no longer necessary)