issue_comments: 474813983

Great that's helpful, thanks. I see what's happening now. There's a lot of tricky things going on, so bear with me.

Let's examine the output from ds.info() related to the time bounds and time variables: float64 time_bound(time, d2) ; time_bound:long_name = boundaries for time-averaging interval ; time_bound:units = days since 0000-01-01 00:00:00 ; float64 time(time) ; time:long_name = time ; time:units = days since 0-1-1 00:00:00 ; time:bounds = time_bnds ; time:calendar = 365_day ; time:standard_name = time ; time:axis = T ; There are a few important things to note: 1. In both the 'time_bound' and 'time' variables, the units attribute contains a reference date with year zero. 2. 'time' has a calendar attribute of '365_day', while a calendar attribute is not specified for the 'time_bound'. 3. 'time' has a 'bounds' attribute that points to a variable named 'time_bnds' instead of 'time_bound'.

For non-real-world calendars (e.g. 365_day), reference dates in cftime should allow year zero. This was fixed upstream in https://github.com/Unidata/netcdf4-python/pull/470. That being said, because of (2), the calendar for 'time_bound' is assumed to be a standard calendar; therefore you get this ValueError when decoding the times: ValueError: zero not allowed as a reference year, does not exist in Julian or Gregorian calendars Ultimately though, with https://github.com/pydata/xarray/pull/2571, we try to propagate the time-related attributes from the time coordinate to the associated bounds coordinate (so in normal circumstances we would use a 365_day calendar in this case as well). But, because of (3), this is not possible due to the fact that the 'bounds' attribute on the 'time' variable points to a variable name that does not exist.

In theory, another possible way to work around this would be to open the dataset with decode_times=False, add the appropriate calendar attribute to 'time_bound', and then decode the times: ds = xr.open_dataset('some_CESM_output_file.nc', decode_times=False) ds.time_bound.attrs['calendar'] = ds.time.attrs['calendar'] ds = xr.decode_cf(ds, use_cftime=True) Now, this may still not work depending on the values in the the 'time_bound' variable (i.e. if any are less than 365.), because cftime currently does not support year zero in date objects (even for non-real-world calendars). I think one could make the argument that this is inconsistent with allowing reference dates with year zero for those date types, so it would probably be worth opening an issue there to try and get that fixed upstream.

In conclusion, I'm afraid there is nothing we can do in xarray to automatically fix this situation. Issue (3) in the netCDF file is particularly unfortunate. If it weren't for that, I think all of these issues would be possible to work around, e.g. with https://github.com/pydata/xarray/pull/2571 here, or with fixes upstream.