issue_comments: 1412439718

Thanks for joining the meeting today @khider. Some potentially relevant places in the code that come to my mind are: - Automatic casting to nanosecond precision - Decoding times via pandas - Encoding times via pandas - datetime_to_numeric

Though as @shoyer says, searching for datetime64[ns] or timedelta64[ns] will probably go a long way toward finding most of these issues.

Some design questions that come to my mind are (but you don't need an answer to these immediately to start working): - How do we decide which precision to decode times to? Would it be the finest precision that enables decoding without overflow? - This is admittedly in the weeds, but how do we decide when to use cftime and when not to? It seems obvious that in the long term we should use NumPy values for proleptic Gregorian dates of all precisions, but what about dates from the Gregorian calendar (where we may no longer have the luxury that the proleptic Gregorian and Gregorian calendars are equivalent for all representable times)? - Not a blocker (since this is an existing issue) but are there ways we could make working with mixed precision datetime values friendlier with regard to overflow (https://github.com/numpy/numpy/issues/16352)? I worry about examples like this:

```
>>> np.seterr(over="raise")
>>> np.datetime64("1970-01-01", "ns") - np.datetime64("0001-01-01", "D")
numpy.timedelta64(6795364578871345152,'ns')
```