issue_comments

I'm also getting the same error:ValueError: unable to decode time units 'months since 1955-01-01 00:00:00' with 'the default calendar'. Try opening your dataset with decode_times=False or installing cftime if it is not installed.

Thank you all for the clarification! I will get in touch with the person who ran the model and get back to you as soon as possible.

@AJueling , do you know the provenance of the file with time.attrs.bounds /= 'time_bound'? If that file is being produced by an NCAR or CESM supplied workflow, then I am willing to see if the workflow can be corrected to keep time.attrs.bounds = 'time_bound'. With this mismatch, it seems hopeless for xarray to automatically figure out how to handle this file as it was intended to be handled.

@rabernat , it is not clear to me that issue 2 is an objective error in the metadata.

The CF conventions section on the bounds attribute states:

Since a boundary variable is considered to be part of a coordinate variable’s metadata, it is not necessary to provide it with attributes such as long_name and units.

Boundary variable attributes which determine the coordinate type (units, standard_name, axis and positive) or those which affect the interpretation of the array values (units, calendar, leap_month, leap_year and month_lengths) must always agree exactly with the same attributes of its associated coordinate, scalar coordinate or auxiliary coordinate variable. To avoid duplication, however, it is recommended that these are not provided to a boundary variable.

I conclude from this that software parsing CF metadata should have the variable identified by the bounds attribute inherit the attributes mentioned above from the variable with the bounds attribute. @spencerkclark describes this as a work around. One could argue that based on the CF conventions text, xarray would be justified in dong that automatically.

However, this is confounded by issue 3, that time.attrs.bounds /= 'time_bound', which I agree is an error in the metadata. As a CESM-POP developer, I'm surprised to see that. Raw model output from CESM-POP has time.attrs.bounds = 'time_bound'. So it seems like something in a post-processing workflow has the net effect of changing time.attrs.bounds, but is preserving the name of the variable bounds. That is problematic.

If CESM-POP were to adhere more closely to the CF recommendation in this section, I think it would drop time_bound.attrs.units, not add time_bound.attrs.calendar. But I don't think that is what you are suggesting.

Opening the file as ds = xr.open_dataset('some_CESM_output_file.nc', decode_times=False) the time coordinate ds.time is at first simply an array of floats: <xarray.DataArray 'time' (time: 1)> array([73020.]) Coordinates: * time (time) float64 7.302e+04 Attributes: long_name: time units: days since 0-1-1 00:00:00 bounds: time_bnds calendar: 365_day standard_name: time axis: T and after decoding xr.decode_cf(ds, use_cftime=True).time returns <xarray.DataArray 'time' (time: 1)> array([cftime.DatetimeNoLeap(200, 1, 21, 0, 0, 0, 0, 3, 21)], dtype=object) Coordinates: * time (time) object 0200-01-21 00:00:00 Attributes: long_name: time bounds: time_bnds standard_name: time axis: T

The traceback of opening the file without decode_times=False complains about year 0 being outside the range of the Gregorian or Julian calendars:

In case anyone is still struggling with the CESM POP time units convention, with the new CF support of version 0.12 the problem is (almost) solved.

I have slightly different CESM POP netcdf output with time attributes {'units': 'days since 0-1-1 00:00:00', 'calendar': '365_day'} and crucially a dimension d2 (without coordinates) that trips up the decode_cf function.

```python import xarray as xr # version >= 0.12

ds = xr.open_dataset('some_CESM_output_file.nc', decode_times=False) ds = ds.drop_dims(['d2']) ds = xr.decode_cf(ds, use_cftime=True) ```

Now the xarray Dataset has a cftime.DatetimeNoLeap type time coordinate.