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/521#issuecomment-474906014,https://api.github.com/repos/pydata/xarray/issues/521,474906014,MDEyOklzc3VlQ29tbWVudDQ3NDkwNjAxNA==,15570875,2019-03-20T16:09:54Z,2019-03-20T16:09:54Z,NONE,"@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.","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,99836561
https://github.com/pydata/xarray/issues/521#issuecomment-474897336,https://api.github.com/repos/pydata/xarray/issues/521,474897336,MDEyOklzc3VlQ29tbWVudDQ3NDg5NzMzNg==,15570875,2019-03-20T15:52:45Z,2019-03-20T15:52:45Z,NONE,"@rabernat , it is not clear to me that issue 2 is an objective error in the metadata.
The [CF conventions](http://cfconventions.org/Data/cf-conventions/cf-conventions-1.7/cf-conventions.html#cell-boundaries) 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.","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,99836561