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
1235725650,I_kwDOAMm_X85Jp61S,6607,Coordinate promotion workaround broken,20629530,closed,0,4160723,,4,2022-05-13T21:20:25Z,2022-09-27T09:33:41Z,2022-09-27T09:33:41Z,CONTRIBUTOR,,,,"### What happened?
Ok so this one is a bit weird. I'm not sure this is a bug, but code that worked before doesn't anymore, so it is some sort of regression.
I have a dataset with one dimension and one coordinate along that one, but they have different names. I want to transform this so that the coordinate name becomes the dimension name so it becomes are proper dimension-coordinate (I don't know how to call it). After renaming the dim to the coord's name, it all looks good in the repr, but the coord still is missing an `index` for that dimension (`crd.indexes` is empty, see MCVE). There was a workaround through `reset_coords` for this, but it doesn't work anymore.
Instead, the last line of the MCVE downgrades the variable, the final `lon` doesn't have coords anymore.
### What did you expect to happen?
In the MCVE below, I show what the old ""workaround"" was. I expected `lon.indexes` to contain the indexes `lon` at the end of the procedure.
### Minimal Complete Verifiable Example
```Python
import xarray as xr
# A dataset with a 1d variable along a dimension
ds = xr.Dataset({'lon': xr.DataArray([1, 2, 3], dims=('x',))})
# Promote to coord. This still is not a proper crd-dim (different name)
ds = ds.set_coords(['lon'])
# Rename dim:
ds = ds.rename(x='lon')
# Now do we have a proper coord-dim ? No. not yet because:
ds.indexes # is empty
# Workaround that was used up to the last release
lon = ds.lon.reset_coords(drop=True)
# Because of the missing indexes the next line fails on the master
lon - lon.diff('lon')
```
### 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](https://mybinder.org/v2/gh/pydata/xarray/main?urlpath=lab/tree/doc/examples/blank_template.ipynb), returning the result.
- [x] New issue — a search of GitHub Issues suggests this is not a duplicate.
### Relevant log output
_No response_
### Anything else we need to know?
My guess is that this line is causing `reset_coords` to drop the coordinate from itself : https://github.com/pydata/xarray/blob/c34ef8a60227720724e90aa11a6266c0026a812a/xarray/core/dataarray.py#L866
It would be nice if the renaming was sufficient for the indexes to appear.
My example is weird I know. The real use case is a script where we receive a 2d coordinate but where all lines are the same, so we take the first line and promote it to a proper coord-dim. But the current code fails on the master on the `lon - lon.diff('lon')` step that happens afterwards.
### Environment
INSTALLED VERSIONS
------------------
commit: None
python: 3.9.12 | packaged by conda-forge | (main, Mar 24 2022, 23:22:55)
[GCC 10.3.0]
python-bits: 64
OS: Linux
OS-release: 5.13.19-2-MANJARO
machine: x86_64
processor:
byteorder: little
LC_ALL: None
LANG: fr_CA.UTF-8
LOCALE: ('fr_CA', 'UTF-8')
libhdf5: None
libnetcdf: None
xarray: 2022.3.1.dev104+gc34ef8a6
pandas: 1.4.2
numpy: 1.22.2
scipy: 1.8.0
netCDF4: None
pydap: installed
h5netcdf: None
h5py: None
Nio: None
zarr: None
cftime: 1.5.2
nc_time_axis: None
PseudoNetCDF: None
rasterio: None
cfgrib: None
iris: None
bottleneck: None
dask: 2022.02.1
distributed: 2022.2.1
matplotlib: None
cartopy: None
seaborn: None
numbagg: None
fsspec: 2022.3.0
cupy: None
pint: None
sparse: 0.13.0
setuptools: 59.8.0
pip: 22.0.3
conda: None
pytest: 7.0.1
IPython: 8.3.0
sphinx: None
","{""url"": ""https://api.github.com/repos/pydata/xarray/issues/6607/reactions"", ""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,completed,13221727,issue
798592803,MDU6SXNzdWU3OTg1OTI4MDM=,4853,cftime default's datetime breaks CFTimeIndex,20629530,open,0,,,4,2021-02-01T18:14:21Z,2021-02-05T18:48:31Z,,CONTRIBUTOR,,,,"
**What happened**:
With `cftime` 1.2.0, one can create datetime object with `cftime.datetime(*args, calendar='calendar')`, instead of using one of the subclasses (ex `cftime.DatetimeNoLeap(*args)`). In the latest release (1.4.0, yesterday), the subclasses have been deprecated, but kept as legacy. While all xr code still works (it is using the legacy subclasses), the `CFTimeIndex` object relies on the _type_ of the datetime object in order to infer the calendar. If the datetime was created outside xarray, using the now default constructor, the returned type is not understood and `CFTimeIndex`breaks.
**What you expected to happen**:
I expected `CFTimeIndex` to be independent of the way the datetime object is created.
**Minimal Complete Verifiable Example**:
```python3
import cftime
import numpy as np
import xarray as xr
# A datetime array, not created in xarray
time = cftime.num2date(np.arange(365), ""days since 2000-01-01"", calendar=""noleap"")
a = xr.DataArray(np.zeros(365), dims=('time',), coords={'time': time})
a.indexes['time']
```
Fails with :
```python3
Traceback (most recent call last):
File """", line 1, in
File ""/home/phobos/Python/xclim/.tox/py38/lib/python3.8/site-packages/xarray/coding/cftimeindex.py"", line 342, in __repr__
attrs_str = format_attrs(self)
File ""/home/phobos/Python/xclim/.tox/py38/lib/python3.8/site-packages/xarray/coding/cftimeindex.py"", line 264, in format_attrs
attrs[""freq""] = f""'{index.freq}'"" if len(index) >= 3 else None
File ""/home/phobos/Python/xclim/.tox/py38/lib/python3.8/site-packages/xarray/coding/cftimeindex.py"", line 692, in freq
return infer_freq(self)
File ""/home/phobos/Python/xclim/.tox/py38/lib/python3.8/site-packages/xarray/coding/frequencies.py"", line 96, in infer_freq
inferer = _CFTimeFrequencyInferer(index)
File ""/home/phobos/Python/xclim/.tox/py38/lib/python3.8/site-packages/xarray/coding/frequencies.py"", line 105, in __init__
self.values = index.asi8
File ""/home/phobos/Python/xclim/.tox/py38/lib/python3.8/site-packages/xarray/coding/cftimeindex.py"", line 673, in asi8
[
File ""/home/phobos/Python/xclim/.tox/py38/lib/python3.8/site-packages/xarray/coding/cftimeindex.py"", line 674, in
_total_microseconds(exact_cftime_datetime_difference(epoch, date))
File ""/home/phobos/Python/xclim/.tox/py38/lib/python3.8/site-packages/xarray/core/resample_cftime.py"", line 370, in exact_cftime_datetime_difference
seconds = b.replace(microsecond=0) - a.replace(microsecond=0)
File ""src/cftime/_cftime.pyx"", line 1153, in cftime._cftime.datetime.__sub__
ValueError: cannot compute the time difference between dates with different calendars
```
**Anything else we need to know?**:
**Environment**:
Output of xr.show_versions()
INSTALLED VERSIONS
------------------
commit: None
python: 3.8.5 | packaged by conda-forge | (default, Jul 31 2020, 02:39:48)
[GCC 7.5.0]
python-bits: 64
OS: Linux
OS-release: 5.10.11-arch1-1
machine: x86_64
processor:
byteorder: little
LC_ALL: None
LANG: fr_CA.utf8
LOCALE: fr_CA.UTF-8
libhdf5: 1.12.0
libnetcdf: 4.7.4
xarray: 0.16.2
pandas: 1.2.1
numpy: 1.20.0
scipy: 1.6.0
netCDF4: 1.5.5.1
pydap: None
h5netcdf: None
h5py: None
Nio: None
zarr: None
cftime: 1.4.0
nc_time_axis: None
PseudoNetCDF: None
rasterio: None
cfgrib: None
iris: None
bottleneck: 1.3.2
dask: 2021.01.1
distributed: None
matplotlib: None
cartopy: None
seaborn: None
numbagg: None
pint: 0.16.1
setuptools: 46.1.3
pip: 20.1
conda: None
pytest: 6.2.2
IPython: 7.19.0
sphinx: None