issue_comments

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.

I opened an issue in cftime regarding this: https://github.com/Unidata/cftime/issues/114.

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.

Thanks -- in looking at the metadata it seems there is nothing unusual about the 'd2' dimension (in normal circumstances we should be able to decode N-D variables to dates, regardless of their type).

My feeling is that the issue here remains the fact that cftime dates do not support year zero (see the upstream issue @rabernat mentioned earlier: Unidata/netcdf4-python#442). That said, it's surprising that dropping the 'time_bounds' variable seems to be a workaround for this issue, because the 'time' variable (which remains in the dataset) still has units with a reference date of year zero.

If you don't mind, could you provide me with two more things? - What the time coordinate looks like after your workaround in https://github.com/pydata/xarray/issues/521#issuecomment-474580481 - What the traceback looks like if you try to open the file normally, e.g. ds = xr.open_dataset('some_CESM_output_file.nc')?

Could you provide the output of ncdump -h or ds.info() on an example file?