issue_comments

In order to maintain a list of currently relevant issues, we mark issues as stale after a period of inactivity If this issue remains relevant, please comment here; otherwise it will be marked as closed automatically

I think using a more informative error when particularly year and month are used would be the right way to go. It would also probably be fine to require integer months/years, but Pandas also has weird behavior:

In[6]: pd.to_timedelta(1, 'M') Out[6]: Timedelta('30 days 10:29:06') In[7]: pd.to_timedelta(1.5, 'M') Out[7]: Timedelta('30 days 10:29:06')

Because of this it would take a significant rework of decode_cf_datetime in conventions.py to actually implement integer months working properly.

@mcgibbon - I'm not sure what to do here then. There is a related discussion here that I think we should follow.

So I think we need a more informative error or to better use whatever error netcdf4 throws.

For the record, I never want a month to equal 30.42 days. I understand why UDUNITS did that (because units should vary with time) -- but they should have taken it up with those who decided on our calendar systems 😉.

@jhamman It does sound sensible to have integer months accepted as a unit. However, Udunits isn't sensible (in this way), and CF conventions refer to Udunits. If we are to treat months as Udunits months, then each month is 30.42 or a similar number of days, and February 1st + 1 month is not the 1st of March.

The CF-compatible way to do it is have the length of a month be based on the length of a year for the current calendar. Even then it's not well defined since a common and leap year are different lengths...

At the very least it should be helpful to see an error message raised explaining why months and years aren't acceptable units when using them is attempted, possibly referring to this github issue.

@mcgibbon - I actually just ran into this today as well. I'd be happy to see something sensible added to our decoding. To start, why don't we only allow decoding of these units when the values are (like) integers. 16 years since 2000-01-01 is easy enough to decode but partial months/years can get tricky and error-prone since 10.84 months since 2016-01-01 requires us to make some decisions about the length of the month/year.

Indeed, NumPy converts these units inconsistently with Udunits:

```

np.timedelta64(1, 'Y').astype('timedelta64[D]') numpy.timedelta64(365,'D') ```

We currently convert all datetime arrays to ns resolution (for pandas compatibility), which means this would give possibly broken results.

But honestly, we haven't looked into this very much. If this would be a uniform improvement over the current state then it's worth considering.

CC @jhamman