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

Yes, let's use pd.to_timedelta. Please mention https://github.com/numpy/numpy/issues/11096 in a comment in the code -- hopefully this should be fixed in the next NumPy release (1.15?).

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.

Any multiple of 7 days (one week) seems to trigger it, e.g., ``` In [133]: np.array([datetime.timedelta(7)], dtype='timedelta64[D]')

TypeError Traceback (most recent call last) <ipython-input-133-92f07e97d8dc> in <module>() ----> 1 np.array([datetime.timedelta(7)], dtype='timedelta64[D]')

TypeError: Cannot cast datetime.timedelta object from metadata [Y] to [D] according to the rule 'same_kind' ```

For now, maybe try casting each element individually to np.timedelta64 as a work-around? e.g., In [139]: np.array([np.timedelta64(d, 'ns') for d in uniques.tolist()]) Out[139]: array([2419200000000000, 2592000000000000, 2678400000000000], dtype='timedelta64[ns]')

This must be a NumPy bug. Here's an even simpler reproduction: ``` import numpy as np import datetime

np.array([datetime.timedelta(28)], dtype='timedelta64[D]')

TypeError: Cannot cast datetime.timedelta object from metadata [Y] to [D] according to the rule 'same_kind'

```

Any other day I've tried works. Also, the following code works (at least on my laptop): In [113]: np.array([datetime.timedelta(27)], dtype='timedelta64[D]'), np.array([datetime.timedelta(28)], dtype='timedelta64[D]') Out[113]: (array([27], dtype='timedelta64[D]'), array([28], dtype='timedelta64[D]'))

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.

I haven't looked into this in detail, but my guess is that this is somehow related to NumPy refusing to convert a timedelta that includes years or months into nanoseconds, because years and months can have different numbers of days.

To help debug this, it would be helpful to know exactly what the input dates is.