issues

• [x] Closes #4955
• [x] Tests added
• [x] Passes pre-commit run --all-files
• [ ] User visible changes (including notable bug fixes) are documented in whats-new.rst

The original issue was about DataArray.set_index, but since this simply calls Dataset.set_index, I have only added a test for the latter. DataArray.set_index probably deserves a test too, please let me know what you think.

Is your feature request related to a problem?

It'd be nice to pass from a chunked DataArray to a dask object directly

Describe the solution you'd like

I think something along these lines should work (although a less convoluted way might exist):

```python import dask.dataframe as dkd import xarray as xr

def to_dask(da: xr.DataArray) -> Union[dkd.Series, dkd.DataFrame]:

if da.data.ndim > 2:
    raise ValueError(f"Can only convert 1D and 2D DataArrays, found {da.data.ndim} dimensions")

indexes = [da.get_index(dim) for dim in da.dims]
darr_index = dka.from_array(indexes[0], chunks=da.data.chunks[0])
columns = [da.name] if da.data.ndim == 1 else indexes[1]
ddf = dkd.from_dask_array(da.data, columns=columns)
ddf[indexes[0].name] = darr_index
return ddf.set_index(indexes[0].name).squeeze()

```

What happened?

When writing a DataArray with CRS information to zarr, after converting it to a Dataset, the CRS is not readable from the zarr file.

What did you expect to happen?

To be able to retrieve the CRS information from the zarr file.

Minimal Complete Verifiable Example

```python da = xr.DataArray(np.arange(9).reshape(3,3), coords={'x':range(3), 'y':range(3)} )

da = da.rio.write_crs(4326) da.to_dataset(name='var').to_zarr('var.zarr') xr.open_zarr('var.zarr')['var'].rio.crs == None # returns True ```

Anything else we need to know?

I'd be happy to have a look at this if it is indeed a bug.

Environment

INSTALLED VERSIONS

commit: None python: 3.9.0 (default, Jan 17 2022, 21:57:22) [GCC 9.3.0] python-bits: 64 OS: Linux OS-release: 5.11.0-1028-aws machine: x86_64 processor: x86_64 byteorder: little LC_ALL: None LANG: C.UTF-8 LOCALE: ('en_US', 'UTF-8') libhdf5: 1.12.1 libnetcdf: None

xarray: 0.20.1 pandas: 1.3.4 numpy: 1.21.4 scipy: 1.7.3 netCDF4: None pydap: None h5netcdf: None h5py: 3.6.0 Nio: None zarr: 2.11.0 cftime: None nc_time_axis: None PseudoNetCDF: None rasterio: 1.2.10 cfgrib: None iris: None bottleneck: None dask: 2022.01.0 distributed: 2022.01.0 matplotlib: 3.5.1 cartopy: None seaborn: None numbagg: None fsspec: 2021.11.1 cupy: None pint: None sparse: None setuptools: 60.2.0 pip: 21.3.1 conda: None pytest: 6.2.5 IPython: 8.0.0 sphinx: None ​

• [x] Closes #5036
• [x] Tests added
• [x] Passes pre-commit run --all-files
• [ ] User visible changes (including notable bug fixes) are documented in whats-new.rst

Not the prettiest of fixes, but this goes around the fact that mutable data types (e.g. when self_data is a np.ndarray) get updated inplace on the right-hand side of the following line, while the error is thrown during the subsequent assignment to the left-hand side.

https://github.com/pydata/xarray/blob/20fddb7e3838d3cf1514476899e77a8a1749734b/xarray/core/variable.py#L2421

• [x] Closes #5240
• [x] Tests added
• [x] Passes pre-commit run --all-files

Technically this creates user visible changes, but not sure whether it's worth adding it to the whatsnew.

• [x] Closes #5679
• [x] Passes pre-commit run --all-files

• [x] Closes #5550
• [x] Tests added
• [x] Passes pre-commit run --all-files
• [x] User visible changes (including notable bug fixes) are documented in whats-new.rst

Regarding https://github.com/pydata/xarray/issues/5550#issuecomment-875040245, inside the for loop only a Variable's dimensions are selected for the transpose, so a dimension that it's missing in all DataArrays would just be ignored silently. Hence it's necessary to check at the beginning of the function.

https://github.com/pydata/xarray/blob/5489effbe7d83451a75382f842c4f5f96ead069f/xarray/core/dataset.py#L4591

A quick fix for a missing commit of PR #5288

• [x] Closes #5199
• [x] Tests added
• [x] Passes pre-commit run --all-files
• [x] User visible changes (including notable bug fixes) are documented in whats-new.rst

Although the error raised by this commit does not include the whole units string, I believe it is actually more useful and specific since it focuses on the part (reference date) that's actually causing the problem. Also, the reference date is the only information available in coding.times._ensure_padded_year, so this is the simplest way of raising an error.

I had a look in tests/test_coding_times.py and could not find a test for this related error raising (since I'd put a test for this commit around there) https://github.com/pydata/xarray/blob/234b40a37e484a795e6b12916315c80d70570b27/xarray/coding/times.py#L127-L129

Have I missed it?

EDIT: I've tried to substitute the error raise on line 129 with a pass and all the tests passed anyway.

• [x] Closes #255
• [x] Tests added
• [x] Passes pre-commit run --all-files
• [x] User visible changes (including notable bug fixes) are documented in whats-new.rst
• [x] New functions/methods are listed in api.rst

• [x] Closes #1123
• [x] Tests added
• [x] Passes pre-commit run --all-files
• [x] User visible changes (including notable bug fixes) are documented in whats-new.rst

Hi xarray folks, long time user first time contributor here.

I believe the tests for this feature should be expanded, so please consider this as a work in progress. Any feedback is greatly appreciated!