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-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