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/628#issuecomment-149929109,https://api.github.com/repos/pydata/xarray/issues/628,149929109,MDEyOklzc3VlQ29tbWVudDE0OTkyOTEwOQ==,2443309,2015-10-21T15:17:54Z,2015-10-21T15:17:54Z,MEMBER,"Certainly, if we get rid of the encoding attribute, we need to keep the time attributes intact. That is a fine solution in my view. I'm not tied to my fix for the coordinates attribute. The balance we need to strike is to not go too far in supporting everything in the CF conventions while not working against supported features in the conventions. ","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,112085412 https://github.com/pydata/xarray/issues/628#issuecomment-149309546,https://api.github.com/repos/pydata/xarray/issues/628,149309546,MDEyOklzc3VlQ29tbWVudDE0OTMwOTU0Ng==,1217238,2015-10-19T18:45:24Z,2015-10-19T18:45:24Z,MEMBER,"I agree that reading a `noleap` calendar and writing it as `standard` seems like a very bad idea. What about simply leaving the calendar attribute intact when reading from netCDF files? I'm less sure about what a good solution looks like for preserving variable specific coordinates. I know you just added that fix, but what are the actual use cases for that information? If coordinates are do not apply to all variables in your dataset, then perhaps an `xray.Dataset` is not the right model for your problem. ","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,112085412 https://github.com/pydata/xarray/issues/628#issuecomment-149240760,https://api.github.com/repos/pydata/xarray/issues/628,149240760,MDEyOklzc3VlQ29tbWVudDE0OTI0MDc2MA==,2443309,2015-10-19T15:01:13Z,2015-10-19T15:01:13Z,MEMBER,"@shoyer - It would be nice to simplify the `Variable` object, however, until `NumPy` can support custom datatypes, I don't think this is very practical. How would you propose we round trip the coordinates and time variables? Reading a time variable with a `noleap` calendar and writing it out as a `standard` calendar seems like a bad idea. In the climate modeling world, non-standard calendars are ubiquitous and I know of many people that have come to `xray` because we (partially) support those calendars. Leaving the `encoding` attribute/dictionary in `Variable` objects seems necessary to continue supporting the netCDF variable/attribute relationships. ","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,112085412