Ensure decoding as datetime64[ns] #59
Conversation
Pandas seems to have trouble constructing multi-indices when it's given datetime64 arrays which don't have ns precision. The current version of decode_cf_datetime will give datetime arrays with the default precision, which is us. Hence, when coupled with the dtype restoring wrapper from PR #54, the `to_series()` and `to_dataframe()` methods were broken when using decoded datetimes.
|
I'll go ahead and merge this in to fix the bug ... but I wonder if there is any way we can avoid using np.datetime64 objects. They seem under-developed / broken. |
Ensure decoding as datetime64[ns]
|
So I think the unfortunate reality is that np.datetime64 is still our best option. Otherwise we are left with dates as Python objects, which is painfully slow. |
|
Yeah, does seem that way. Unfortunately that makes comparison with datetime objects a bit awkward. Perhaps we should include a to_datetime() the way pandas does? Certainly, it would be convenient to be able to do comparisons such as: ds['time'].data > datetime.datetime(2014, 01, 01) This is definitely not high priority though. |
|
If you're sure that 'time' is stored as |
* think I've fixed the bug * used feature from python 3.9 * test but doesn't yet work properly * only check subtree, not down to root * add parent info to repr * trigger CI
Pandas seems to have trouble constructing multi-indices when it's given
datetime64 arrays which don't have ns precision. The current version of
decode_cf_datetime will give datetime arrays with the default precision, which
is us. Hence, when coupled with the dtype restoring wrapper from PR #54, the
to_series()andto_dataframe()methods were broken when using decodeddatetimes.