`rolling_exp` loses coords

[max-sixty]

What happened?

We lose the time coord here — Dimensions without coordinates: time:

ds = xr.tutorial.load_dataset("air_temperature")
ds.rolling_exp(time=5).mean()

<xarray.Dataset>
Dimensions:  (lat: 25, time: 2920, lon: 53)
Coordinates:
  * lat      (lat) float32 75.0 72.5 70.0 67.5 65.0 ... 25.0 22.5 20.0 17.5 15.0
  * lon      (lon) float32 200.0 202.5 205.0 207.5 ... 322.5 325.0 327.5 330.0
Dimensions without coordinates: time
Data variables:
    air      (time, lat, lon) float32 241.2 242.5 243.5 ... 296.4 296.1 295.7

(I realize I wrote this, I didn't think this used to happen, but either it always did or I didn't write good enough tests... mea culpa)

What did you expect to happen?

We keep the time coords, like we do for normal rolling:

In [2]: ds.rolling(time=5).mean()
Out[2]:
<xarray.Dataset>
Dimensions:  (lat: 25, lon: 53, time: 2920)
Coordinates:
  * lat      (lat) float32 75.0 72.5 70.0 67.5 65.0 ... 25.0 22.5 20.0 17.5 15.0
  * lon      (lon) float32 200.0 202.5 205.0 207.5 ... 322.5 325.0 327.5 330.0
  * time     (time) datetime64[ns] 2013-01-01 ... 2014-12-31T18:00:00

Minimal Complete Verifiable Example

(as above)

MVCE confirmation

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

Relevant log output

No response

Anything else we need to know?

No response

Environment

INSTALLED VERSIONS

commit: None
python: 3.9.13 (main, May 24 2022, 21:13:51)
[Clang 13.1.6 (clang-1316.0.21.2)]
python-bits: 64
OS: Darwin
OS-release: 21.6.0
machine: arm64
processor: arm
byteorder: little
LC_ALL: en_US.UTF-8
LANG: None
LOCALE: ('en_US', 'UTF-8')
libhdf5: None
libnetcdf: None

xarray: 2022.6.0
pandas: 1.4.3
numpy: 1.21.6
scipy: 1.8.1
netCDF4: None
pydap: None
h5netcdf: None
h5py: None
Nio: None
zarr: 2.12.0
cftime: None
nc_time_axis: None
PseudoNetCDF: None
rasterio: None
cfgrib: None
iris: None
bottleneck: None
dask: 2021.12.0
distributed: 2021.12.0
matplotlib: 3.5.1
cartopy: None
seaborn: None
numbagg: 0.2.1
fsspec: 2021.11.1
cupy: None
pint: None
sparse: None
flox: None
numpy_groupies: None
setuptools: 62.3.2
pip: 22.1.2
conda: None
pytest: 7.1.2
IPython: 8.4.0
sphinx: 4.3.2

[headtr1ck]

This is actually a bug in Dataset.reduce, it will drop the time index as well.
See this example:

da = xr.DataArray([[1, 2, 3], [4, 5, 6]], dims=["x", "y"], coords={"x": [5, 6]})
da.reduce(lambda x, *_, **__: x, dim="x")  # has time coord

ds = xr.Dataset({"a": da})
ds.reduce(lambda x, *_, **__: x, dim="x")  # lost time coord

Probably the assumtion when writing this code was that the passed function actually reduces the dim.

[headtr1ck]

The logic of figuring out what stays and what goes is different in DataArray and Dataset.
DataArray reduces the variable and then kicks out all dims, coords, indexes that don't fit anymore.
Dataset tries to do the selection on the fly (and apparently fails to do so).

[dcherian]

Seems like we should transition this to apply_ufunc.

[max-sixty]

Is there any reason not to use apply_ufunc? I've spent 15 mins searching issues to try and work out why this existed — I had a faint memory there was some reason behind hit, but couldn't find anything.

There's a suggestion from @dcherian to change other reduce methods to use apply_ufunc: #7152 (comment)