What happened?

When I try to run a modified version of the example from the dropna documentation (see below), it creates a never terminating process. To reproduce it I added a rolling operation before dropping nans and then run 4 processes using the standard library multiprocessing Pool class on DaskArrays. Running the rolling + dropna in a for loop finishes as expectedly in no time.

What did you expect to happen?

There is nothing obvious to me why this wouldn't just work unless there is a weird interaction between the Dask threads and the different processes. Using Xarray+Dask+Multiprocessing seems to work for me on other functions, it seems to be this particular combination that is problematic.

Minimal Complete Verifiable Example

```Python import xarray as xr import numpy as np from multiprocessing import Pool

datasets = [xr.Dataset( { "temperature": ( ["time", "location"], [[23.4, 24.1], [np.nan if i>1 else 23.4, 22.1 if i<2 else np.nan], [21.8 if i<3 else np.nan, 24.2], [20.5, 25.3]], ) }, coords={"time": [1, 2, 3, 4], "location": ["A", "B"]}, ).chunk(time=2) for i in range(4)]

def process(dataset): return dataset.rolling(dim={'time':2}).sum().dropna(dim="time", how="all").compute()

This works as expected

dropped = [] for dataset in datasets: dropped.append(process(dataset))

This seems to never finish

with Pool(4) as p: dropped = p.map(process, datasets) ```

MVCE confirmation

• [X] Minimal example — the example is as focused as reasonably possible to demonstrate the underlying issue in xarray.
• [X] Complete example — the example is self-contained, including all data and the text of any traceback.
• [X] Verifiable example — the example copy & pastes into an IPython prompt or Binder notebook, returning the result.
• [X] New issue — a search of GitHub Issues suggests this is not a duplicate.
• [ ] Recent environment — the issue occurs with the latest version of xarray and its dependencies.

Relevant log output

No response

Anything else we need to know?

I am still running on 2023.08.0 see below for more details about the environment

Environment

• Updates the docstring for persist to mention that it is not altering the original object.

• Adds a return value to the docstring for compute and persist on both Dataset and DataArray

• [x] Closes #8901

What is your issue?

I am playing around with using Dataset.persist and assumed it would work like .load. I also just looked at the source code and it looks to me like it should indeed replace the original data but I can see both in performance and the dask dashboard that steps are recomputed if I don't use the object returned by .persist which points me towards .persist behaving more like .compute.

In either case, I would make a PR to clarify in the docs whether persists leaves the original data untouched or not.

Simply adds datetime.date to plottable types in _ensure_plottable in plot/utils.pyL675 to enable the plotting of dates.

Matplotlib handles date types automatically, so I think there is no other change needed.

Do I need to add a test for this? Any pointers on where I would put it that?

• [x] Closes #8866
• [x] Tests added
• [x] User visible changes (including notable bug fixes) are documented in whats-new.rst
• [x] New functions/methods are listed in api.rst

What happened?

I noticed that xarray doesnt support plotting when the x-axis is a datetime.date. In my case, I would like to plot hourly data aggregated by date. I know that in this particular case, I could just use .resample('1D') to achieve the same result and be able to plot it but I am wondering whether xarray shouldn't just also support plotting dates.

I am pretty sure that matplotlib supports date on the x-axis so maybe adding it to an acceptable type in plot/utils.py L675 in _ensure_plottable would already do the trick?

I am happy to look into this if this is a wanted feature.

What did you expect to happen?

No response

Minimal Complete Verifiable Example

```Python import xarray as xr import numpy as np import datetime start = datetime.datetime(2024, 1,1) time = [start + datetime.timedelta(hours=x) for x in range(720)]

data = xr.DataArray(np.random.randn(len(time)), coords=dict(time=('time', time))) data.groupby('time.date').mean().plot() ```

MVCE confirmation

• [X] Minimal example — the example is as focused as reasonably possible to demonstrate the underlying issue in xarray.
• [X] Complete example — the example is self-contained, including all data and the text of any traceback.
• [X] Verifiable example — the example copy & pastes into an IPython prompt or Binder notebook, returning the result.
• [X] New issue — a search of GitHub Issues suggests this is not a duplicate.
• [ ] Recent environment — the issue occurs with the latest version of xarray and its dependencies.

Relevant log output

Python TypeError: Plotting requires coordinates to be numeric, boolean, or dates of type numpy.datetime64, datetime.datetime, cftime.datetime or pandas.Interval. Received data of type object instead.

Anything else we need to know?

No response

Environment

What happened?

I am trying to save an xr.Dataset that I read and processed from another saved zarr file. But it fails with this error

numcodecs/vlen.pyx in numcodecs.vlen.VLenUTF8.encode() TypeError: expected unicode string, found 3 It seems like the first time the dataset is saved, xarray/zarr is adding a VLenUTF8 filter to the encoding of one of the dimensions. If I pop the filters key from the opened dataset I can resave the file.

I can also safely save to netcdf (which makes sense since this encoding is probably ignored then).

What did you expect to happen?

I should be able to open and resave a file to zarr.

Minimal Complete Verifiable Example

```Python import xarray as xr import numpy as np da= xr.DataArray(np.array(['126469-423', '130042-0-10046', '120259-10343'], dtype='object'), dims=['asset'], name='asset')

da.to_dataset().to_zarr('~/Downloads/test.zarr', mode='w')

Fails with the error below

opened = xr.open_zarr('~/Downloads/test.zarr') opened.to_zarr('~/Downloads/test2.zarr', mode='w')

Saves successfully

opened.asset.encoding.pop('filters') opened.to_zarr('~Downloads/test2.zarr', mode='w')

```

MVCE confirmation

• [X] Minimal example — the example is as focused as reasonably possible to demonstrate the underlying issue in xarray.
• [X] Complete example — the example is self-contained, including all data and the text of any traceback.
• [X] Verifiable example — the example copy & pastes into an IPython prompt or Binder notebook, returning the result.
• [X] New issue — a search of GitHub Issues suggests this is not a duplicate.

Relevant log output

```Python TypeError Traceback (most recent call last) <ipython-input-16-b1f2f1d2b5a0> in <module> 6 opened = xr.open_zarr('~/Downloads/test.zarr') 7 ----> 8 opened.to_zarr('~/Downloads/test2.zarr', mode='w')

~/micromamba/envs/xr/lib/python3.8/site-packages/xarray/core/dataset.py in to_zarr(self, store, chunk_store, mode, synchronizer, group, encoding, compute, consolidated, append_dim, region, safe_chunks, storage_options, zarr_version) 2097 from xarray.backends.api import to_zarr 2098 -> 2099 return to_zarr( # type: ignore 2100 self, 2101 store=store,

~/micromamba/envs/xr/lib/python3.8/site-packages/xarray/backends/api.py in to_zarr(dataset, store, chunk_store, mode, synchronizer, group, encoding, compute, consolidated, append_dim, region, safe_chunks, storage_options, zarr_version) 1668 writer = ArrayWriter() 1669 # TODO: figure out how to properly handle unlimited_dims -> 1670 dump_to_store(dataset, zstore, writer, encoding=encoding) 1671 writes = writer.sync(compute=compute) 1672

~/micromamba/envs/xr/lib/python3.8/site-packages/xarray/backends/api.py in dump_to_store(dataset, store, writer, encoder, encoding, unlimited_dims) 1277 variables, attrs = encoder(variables, attrs) 1278 -> 1279 store.store(variables, attrs, check_encoding, writer, unlimited_dims=unlimited_dims) ... 2112 # check object encoding

numcodecs/vlen.pyx in numcodecs.vlen.VLenUTF8.encode()

TypeError: expected unicode string, found 3 ```

Anything else we need to know?

No response

Environment