issue_comments

Awesome, thanks for tracking that down in NumPy so quickly! I updated #2128 accordingly.

Huh...my test is still triggering some failures due to this issue in #2128. Oddly on my laptop the original bug doesn't appear to exist if I use python version 3.6.5 and numpy version 1.14.3 (the versions on Travis where I'm getting a failure): ``` $ python Python 3.6.5 | packaged by conda-forge | (default, Apr 6 2018, 13:44:09) [GCC 4.2.1 Compatible Apple LLVM 6.1.0 (clang-602.0.53)] on darwin Type "help", "copyright", "credits" or "license" for more information.

import numpy as np np.version '1.14.3' import datetime np.array([datetime.timedelta(7)], dtype='timedelta64[D]') array([7], dtype='timedelta64[D]') and not surprisingly the test passes: $ pytest -vv test_coding_times.py -k test_infer_cftime_datetime_units ========================================================= test session starts ========================================================== platform darwin -- Python 3.6.5, pytest-3.5.1, py-1.5.3, pluggy-0.6.0 -- //anaconda/envs/xarray-docs/bin/python cachedir: ../../.pytest_cache rootdir: /Users/spencerclark/xarray-dev/xarray, inifile: setup.cfg collected 269 items / 268 deselected

test_coding_times.py::test_infer_cftime_datetime_units PASSED [100%] So it appears to be platform dependent. Trying this out on a linux machine with these versions I can reproduce the issue (which seems to persist even for individual timedeltas, explaining the test failure): $ python Python 3.6.5 | packaged by conda-forge | (default, Apr 6 2018, 13:39:56) [GCC 4.8.2 20140120 (Red Hat 4.8.2-15)] on linux Type "help", "copyright", "credits" or "license" for more information.

import numpy as np np.version '1.14.3' import datetime np.array([datetime.timedelta(7)], dtype='timedelta64[D]') Traceback (most recent call last): File "<stdin>", line 1, in <module> TypeError: Cannot cast datetime.timedelta object from metadata [Y] to [D] according to the rule 'same_kind' np.timedelta64(datetime.timedelta(7), 'D') Traceback (most recent call last): File "<stdin>", line 1, in <module> TypeError: Cannot cast datetime.timedelta object from metadata [Y] to [D] according to the rule 'same_kind' np.timedelta64(datetime.timedelta(1), 'D') numpy.timedelta64(1,'D') It's not ideal, but should we try to go with pandas to do the type conversion? It seems to work on the linux platform: import pandas as pd pd.to_timedelta([datetime.timedelta(7)]) TimedeltaIndex(['7 days'], dtype='timedelta64[ns]', freq=None) pd.to_timedelta([datetime.timedelta(7)]).values array([604800000000000], dtype='timedelta64[ns]') ```

Any multiple of 7 days (one week) seems to trigger it

Interesting, thanks for investigating things further and confirming that it likely is a NumPy bug. I put up a fix following your suggestion in #2128 and also included a test.

It's confusing to me, because I don't see where NumPy is getting years or months metadata from the datetime.timedelta objects formed by np.diff(dates): In [12]: np.diff(dates) Out[12]: array([datetime.timedelta(31), datetime.timedelta(28), datetime.timedelta(31), datetime.timedelta(30), datetime.timedelta(31), datetime.timedelta(30), datetime.timedelta(31), datetime.timedelta(31), datetime.timedelta(30), datetime.timedelta(31), datetime.timedelta(30), datetime.timedelta(31), datetime.timedelta(31), datetime.timedelta(28), datetime.timedelta(31), datetime.timedelta(30), datetime.timedelta(31), datetime.timedelta(30), datetime.timedelta(31), datetime.timedelta(31), datetime.timedelta(30), datetime.timedelta(31), datetime.timedelta(30)], dtype=object) Unlike np.timedelta64 objects, datetime.timedelta objects cannot be composed of units which have a varying length depending on the year (the coarsest internal resolution is days). The problem seems to occur only after calling np.unique; maybe the solution is to do the type conversion before calling np.unique? In [19]: np.unique(np.diff(dates).astype('timedelta64[ns]')) Out[19]: array([2419200000000000, 2592000000000000, 2678400000000000], dtype='timedelta64[ns]')

With the specified dates in line 5 of my example, one can reproduce the error (see line 9 in the problem description). Line 10 shows that casting the result of np.unique(np.diff(dates)) as an array seems to make this type conversion work.