issue_comments

I'm pretty sure this used to work in some form. I definitely worked with a dataset in the infancy of xarray that had coordinates with missing times.

The current issue appears to be that pandas represents the NaT values as an integer, and then (predictably) suffers from numeric overflow: ``` In [8]: import pandas as pd

In [9]: pd.to_timedelta(['24658 days 11:15:00', 'NaT']) + pd.Timestamp('1950-01-01')

OverflowError Traceback (most recent call last) <ipython-input-9-cc287bf4c401> in <module>() ----> 1 pd.to_timedelta(['24658 days 11:15:00', 'NaT']) + pd.Timestamp('1950-01-01')

~/conda/envs/xarray-py36/lib/python3.6/site-packages/pandas/core/indexes/datetimelike.py in add(self, other) 658 return self.shift(other) 659 elif isinstance(other, (Timestamp, datetime)): --> 660 return self._add_datelike(other) 661 else: # pragma: no cover 662 return NotImplemented

~/conda/envs/xarray-py36/lib/python3.6/site-packages/pandas/core/indexes/timedeltas.py in _add_datelike(self, other) 354 other = Timestamp(other) 355 i8 = self.asi8 --> 356 result = checked_add_with_arr(i8, other.value) 357 result = self._maybe_mask_results(result, fill_value=iNaT) 358 return DatetimeIndex(result, name=self.name, copy=False)

~/conda/envs/xarray-py36/lib/python3.6/site-packages/pandas/core/algorithms.py in checked_add_with_arr(arr, b, arr_mask, b_mask) 889 890 if to_raise: --> 891 raise OverflowError("Overflow in int64 addition") 892 return arr + b 893

OverflowError: Overflow in int64 addition ```

This appears to be specific to our use of a TimedeltaIndex. Overflow doesn't appear if you add either value as scalars: ``` In [11]: pd.NaT + pd.Timestamp('1950-01-01') Out[11]: NaT

In [12]: pd.Timedelta('24658 days 11:15:00') + pd.Timestamp('1950-01-01') Out[12]: Timestamp('2017-07-06 11:15:00') ```

Hi Guillaume! Nice to see so many old friends showing up on the xarray repo...

The issue you raise is totally reasonable from a user perspective: missing values in datetime data should be permitted. But there are some upstream issues that make it challenging to solve (like most of our headaches related to datetime data).

In numpy (and computer arithmetic in general), NaN only exists in floating point datatypes. It is impossible to have a numpy datetime array with NaN in it: ```python

a = np.array(['2010-01-01', '2010-01-02'], dtype='datetime64[ns]') a[0] = np.nan ValueError: Could not convert object to NumPy datetime `` The same error would be raised ifawere an integer array; to get around that, xarray automatically casts integers with missing data to floats. But that approach obviously doesn't work withdatetime` dtypes.

Further downstream, xarray relies on netcdf4-python's num2date function to decode the date. The error is raised by that package.

This is my understanding of the problem. Some other folks here like @jhamman and @spencerkclark might have ideas about how to solve it. They are working on a new package called netcdftime which will isolate and hopefully enhance such time encoding / decoding functions.