id,node_id,number,title,user,state,locked,assignee,milestone,comments,created_at,updated_at,closed_at,author_association,active_lock_reason,draft,pull_request,body,reactions,performed_via_github_app,state_reason,repo,type
221387277,MDU6SXNzdWUyMjEzODcyNzc=,1372,decode_cf() loads chunked arrays,4992424,closed,0,,,7,2017-04-12T20:52:48Z,2018-04-12T23:38:02Z,2018-04-12T23:38:02Z,NONE,,,,"Currently using xarray version 0.9.2 and dask version 0.14.0.

Suppose you load a NetCDF file with the **chunks** parameter:

``` python
ds = xr.open_dataset(""my_data.nc"", decode_cf=False, chunks={'lon': 10, 'lat': 10})
```

The data is loaded as dask arrays, as expected. But if we then manually call `xarray.decode_cf()`, it'll eagerly load the data. Is this the expected behavior, or should `decode_cf()` preserve the laziness of the data?","{""url"": ""https://api.github.com/repos/pydata/xarray/issues/1372/reactions"", ""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,completed,13221727,issue
121740837,MDU6SXNzdWUxMjE3NDA4Mzc=,678,Save to netCDF with record dimension?,4992424,closed,0,,,6,2015-12-11T16:20:35Z,2018-01-08T20:11:27Z,2018-01-08T20:11:27Z,NONE,,,,"Is it currently possible in xray to identify a coordinate as a record dimension when saving to netCDF? Saving a Dataset to disk - even when it's a Dataset that was directly read in from a netCDF file with a record dimension - seems to destroy any indication that there was a record dimension. For instance, reading in CESM output tapes and then immediately saving them to disk demotes ""time"" from being a record dimension. 
","{""url"": ""https://api.github.com/repos/pydata/xarray/issues/678/reactions"", ""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,completed,13221727,issue
208215185,MDExOlB1bGxSZXF1ZXN0MTA2NTkyMjUx,1272,Groupby-like API for resampling,4992424,closed,0,,2415632,27,2017-02-16T19:04:07Z,2017-09-22T16:27:36Z,2017-09-22T16:27:35Z,NONE,,0,pydata/xarray/pulls/1272,"This is a work-in-progress to resolve #1269. 

- [x] Basic functionality
- [x] Cleanly deprecate old API 
- [x] New test cases
- [x] Documentation / examples
- [x] ""What's new""

Openly welcome feedback/critiques on how I approached this. Subclassing `Data{Array/set}GroupBy` may not be the best way, but it would be easy enough to re-write the necessary helper functions (just `apply()`, I think) so that we do not need to inherit form them directly. Additional issues I'm working to resolve:

- [x] I tried make sure that calls using the old API won't break by refactoring the old logic to `_resample_immediately()`. This may not be the best approach!
- [x] Similarly, I copied all the original test cases and added the suffix `..._old_api`; these could trivially be placed into their related test cases for the new API.
- [x] BUG: **keep_attrs** is ignored when you call it on methods chained to `Dataset.resample()`. Oddly enough, if I hard-code **keep_attrs=True** inside `reduce_array()` in `DatasetResample::reduce` it works just fine. I haven't figured out where the kwarg is getting lost.
- [x] BUG: Some of the test cases (for instance, `test_resample_old_vs_new_api`) fail because the resampling by calling `self.groupby_cls` ends up not working - it crashes because the group sizes that get computed are not what it expects. Occurs with both new and old API","{""url"": ""https://api.github.com/repos/pydata/xarray/issues/1272/reactions"", ""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,,13221727,pull
220011864,MDExOlB1bGxSZXF1ZXN0MTE0NjgwMzcy,1356,Add DatetimeAccessor for accessing datetime fields via `.dt` attribute,4992424,closed,0,,,9,2017-04-06T19:48:19Z,2017-04-29T01:19:12Z,2017-04-29T01:18:59Z,NONE,,0,pydata/xarray/pulls/1356," - [x] Partially closes #358 
 - [x] tests added / passed
 - [x] passes ``git diff upstream/master | flake8 --diff``
 - [x] whatsnew entry

This uses the `register_dataarray_accessor` to add attributes similar to those in pandas` timeseries which let the users quickly access datetime fields from an underlying array of datetime-like values. The referenced issue (#358) also asks about adding similar accessors for `.str`, but this is a more complex topic - I think a compelling use-case would help in figuring out what the critical functionality is

## Virtual time fields

Presumably this could be used to augment `Dataset._get_virtual_variable()`. A **season** field would need to be added as a special field to the accessor.","{""url"": ""https://api.github.com/repos/pydata/xarray/issues/1356/reactions"", ""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,,13221727,pull