issue_comments

What is still missing once 0.12 is released (plotting and resampling)? I don't have the full overview there.

@mathause indeed we've made a lot of progress. A few remaining missing things that come to mind (there could be others) are: - Support for missing values in arrays of cftime objects (I should probably create an issue for this) - Possible PeriodIndex-like functionality with cftime objects (#2481) - coarsen (coming in the next version of xarray) still needs to be updated to work with cftime coordinates (waiting on #2668 before starting on that)

Out of those three, coarsen is probably the highest priority on my list at the moment (the other two would require some more careful thought).

Thanks for your thoughts @shoyer; I like your suggested approach.

From a design perspective, I would consider adding an optional use_cftime argument: - The default value use_cftime=None would match current behavior use_cftime=Truewould mean always use cftime (no warnings) -use_cftime=False` would mean never use cftime (error instead)

+1 for adding an option to always use CF datetimes. I would probably start with putting it on open_dataset() rather than making it global -- local options make it much easier to follow control flow.

I just ran into the problem trying to xr.concat two files - one that runs from 2000 to 2150, the second from 2151 to 2300. They have a mix of Timestamp and cftime.DatetimeGregorian in the time vector which, obviously can not be saved to disk. (I.e. concat worked but not to_netcdf).

Yes, I meant this warning.

Thanks, I understand better now - it makes sense to throw a warning when you unexpectedly get a cftime instead of pandas dates.

An option might be a good way to get consistent datetimes. Especially as the capabilities with cftime are progressing. What is still missing once 0.12 is released (plotting and resampling)? I don't have the full overview there.

Btw: I am really thrilled to be able to have datetime irrespective of the calendar.

Thanks @mathause -- I'm assuming you are referring to this warning, rather than an error? //anaconda/envs/xarray-dev-37/bin/ipython:2: SerializationWarning: Unable to decode time axis into full numpy.datetime64 objects, continuing using dummy cftime.datetime objects instead, reason: dates out of range The rationale for keeping this warning is that for standard calendars (like 'proleptic_gregorian') we use pandas/NumPy dates by default; therefore falling back to using cftime in this circumstance is a deviation from the default behavior, which might come as a surprise to some users.

I wonder if it might make sense to offer an option in xarray to always decode times to cftime dates, even for standard calendar dates between years 1678 and 2262 (which, if set, could also silence this warning); this would be another possible solution for #1263.