html_url,issue_url,id,node_id,user,created_at,updated_at,author_association,body,reactions,performed_via_github_app,issue
https://github.com/pydata/xarray/issues/2921#issuecomment-492713273,https://api.github.com/repos/pydata/xarray/issues/2921,492713273,MDEyOklzc3VlQ29tbWVudDQ5MjcxMzI3Mw==,10194086,2019-05-15T15:52:12Z,2019-05-15T15:52:12Z,MEMBER,"Today @lukasbrunner and me ran into this problem. Opening an mfdataset and saving `to_netcdf`led to the following units for `time` and `time_units`:

    time_bnds:units = ""days since 1850-01-01"" ;
    time:units = ""days since 2000-01-01"" ;

Opening the dataset in `xarray` works fine, but `ncdump` and `ncview` use the units from `time` for `time_bnds`. Thus if I do

    ncdump -tv time_bnds test.nc 

the first date is `'2150-01-01'` (instead of `'2000-01-01'`) - very confusing. (`panoply` shows the correct `time_bnds`).

## Workaround

``` python
import xarray as xr
filenames = ['file1.nc', 'file2.nc']

ds = xr.open_mfdataset(fNs)
ds.load()

# make sure the encoding is really empty
assert not ds.time.encoding

# assign encoding, such that they are equal
ds.time.encoding.update(ds.time_bnds.encoding)

# save
ds.to_netcdf('~/F/test.nc')

```

Btw. thanks to @klindsay28 for the nice error report.","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,437418525
https://github.com/pydata/xarray/issues/2921#issuecomment-490177469,https://api.github.com/repos/pydata/xarray/issues/2921,490177469,MDEyOklzc3VlQ29tbWVudDQ5MDE3NzQ2OQ==,6628425,2019-05-07T17:37:28Z,2019-05-07T17:37:28Z,MEMBER,"> We already have special treatment for time_bounds in the decode step. It makes sense to treat it specially in the encode step.

+1 I didn't fully appreciate how strict the CF conventions were regarding this at the time of #2571.  Where it is unambiguous I agree we should make an effort to comply (or preserve compliance).","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,437418525
https://github.com/pydata/xarray/issues/2921#issuecomment-490143871,https://api.github.com/repos/pydata/xarray/issues/2921,490143871,MDEyOklzc3VlQ29tbWVudDQ5MDE0Mzg3MQ==,2448579,2019-05-07T16:04:58Z,2019-05-07T16:06:39Z,MEMBER,"Thanks for the great report @klindsay28. 

Looks like [CF recommends ](http://cfconventions.org/cf-conventions/cf-conventions.html#cell-boundaries) that `time_bounds` (boundary variable) not have the `units` or `calendar` attributes:
> 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.

We already have special treatment for `time_bounds` in the decode step. It makes sense to treat it specially in the encode step. In fact it looks like @spencerkclark identified this issue in https://github.com/pydata/xarray/pull/2571 :clap:

@klindsay28 Any interest in putting together a PR that would avoid setting these attributes on `time_bounds` during the encode step?

Ping @fmaussion for feedback.","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,437418525