datetime units interpretation wrong in special cases

[forman]

Hi there,

I have a datetime issue with a certain type of (CF-compliant!) netCDF files orginating from the ESA CCI Sea Surface Temperature project. With other climate data, everthings seems fine.

When I open such a netCDF file, the datetime value(s) of the time dimension seem to be wrong. If I do

ds = xr.open_dataset(nc_path)
ds.analysed_sst

I get

<xarray.DataArray 'analysed_sst' (time: 1, lat: 3600, lon: 7200)>
[25920000 values with dtype=float64]
Coordinates:
  * time     (time) datetime64[ns] 1947-05-12T09:58:14
  * lat      (lat) float32 -89.975 -89.925 -89.875 -89.825 -89.775 -89.725 ...
  * lon      (lon) float32 -179.975 -179.925 -179.875 -179.825 -179.775 ...
Attributes:
    units: kelvin
    ...

The time dimension is

    int time(time=1);
      :units = "seconds since 1981-01-01 00:00:00";
      :standard_name = "time";
      :axis = "T";
      :calendar = "gregorian";
      :bounds = "time_bnds";
      :comment = "";
      :long_name = "reference time of sst file";
      :_ChunkSizes = 1; // int

and the time value is 915192000. Therefore the correctly interpreted time value must be 2010-01-01T12:00:00 which is 1981-01-01 00:00:00 plus 915192000 seconds.

Here is the link to the data: ftp://anon-ftp.ceda.ac.uk/neodc/esacci/sst/data/lt/Analysis/L4/v01.1/2010/01/01/20100101120000-ESACCI-L4_GHRSST-SSTdepth-OSTIA-GLOB_LT-v02.0-fv01.1.nc

I'm not sure whether this is actually a CF-specific issue with which xarray doesn't want to deal with. If so, could you please give some advice to get arround this. I'm sure other xarray lovers will face this issue sooner or later.

Thanks!
-- Norman

[shoyer]

This may be related to #545

Likely this is due to numeric overflow of some sort in our datetime decoding function. This is the internal function that handles decoding dates if you're interested in digging into this:
https://github.com/pydata/xarray/blob/v0.7.2/xarray/conventions.py#L115

[forman]

Thanks, I'll give it a try.

[forman]

After some testing I found the problem. The single value of the time coordinate is wrong in the files. So it is a file content problem not a problem in the software. Therefore I'll close this issue.

However, Panoply displays the time information correctly and I found out why: Panoply correctly interprets the time_bnds variable to which the time coordinate variable points to via its attribute bounds. Since this is conforming to CF, I wonder whether xarray should support this bounds convention. From the CF conventions 1.6:

It is often the case that data values are not representative of single points in time and/or space, but rather of intervals or multidimensional cells. This convention defines a bounds attribute to specify the extent of intervals or cells. When data that is representative of cells can be described by simple statistical methods, those methods can be indicated using the cell_methods attribute. An important application of this attribute is to describe climatological and diurnal statistics.

Details are in Section 7.1 Cell Boundaries