Repository navigation
Description
What happened?
A RangeIndex built from datetime64 start/stop and a timedelta64 step works: labels are computed correctly, and isel and sel(method="nearest") keep the index lazy. But its repr formats start, stop and step with :.3g, which only real numbers accept, so printing the index, or any DataArray/Dataset which holds it, raises.
A lazy time axis is the main reason we want RangeIndex: a long, evenly sampled acquisition has 1e8+ time labels and a handful of channels, so the time coordinate is the one worth not materializing.
What did you expect to happen?
The repr to print, as it does for a float range, e.g.
Indexes:
time RangeIndex (start=2023-01-01T00:00:00.000000000, stop=2023-01-01T00:00:10.000000000, step=1 seconds)
Minimal Complete Verifiable Example
# /// script
# requires-python = ">=3.11"
# dependencies = [
# "xarray[complete]@git+https://github.com/pydata/xarray.git@main",
# ]
# ///
#
# This script automatically imports the development branch of xarray to check for issues.
# Please delete this header if you have _not_ tested this script with `uv run`!
import xarray as xr
import numpy as np
from xarray.indexes import RangeIndex
xr.show_versions()
t0 = np.datetime64("2023-01-01", "ns")
step = np.timedelta64(1, "s")
index = RangeIndex.arange(t0, t0 + 10 * step, step, dim="time")
da = xr.DataArray(np.zeros(10), dims="time", coords=xr.Coordinates.from_xindex(index))
print(da.time.values[:2]) # ['2023-01-01T00:00:00.000000000' '2023-01-01T00:00:01.000000000']
print(da)Steps to reproduce
Just run it
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.
- Recent environment — the issue occurs with the latest version of xarray and its dependencies.
Relevant log output
Anything else we need to know?
No response
Environment
Details
Reproduced on both, in clean uv environments:
xarray 2026.7.0 (latest release)
xarray 2026.7.1.dev56+g8de862c29 (main at commit 8de862c, 2026-09-21)
INSTALLED VERSIONS
commit: None
python: 3.13.1 (main, Dec 6 2024, 18:40:43) [Clang 18.1.8 ]
python-bits: 64
OS: Linux
OS-release: 7.0.0-31-generic
machine: x86_64
processor: x86_64
byteorder: little
LC_ALL: None
LANG: en_US.UTF-8
LOCALE: ('en_US', 'UTF-8')
libhdf5: None
libnetcdf: None
xarray: 2026.7.0
pandas: 3.0.6
numpy: 2.5.3
scipy: None
netCDF4: None
pydap: None
h5netcdf: None
h5py: None
zarr: None
cftime: None
nc_time_axis: None
iris: None
bottleneck: None
dask: None
distributed: None
matplotlib: None
cartopy: None
seaborn: None
numbagg: None
fsspec: None
cupy: None
pint: None
sparse: None
flox: None
numpy_groupies: None
setuptools: None
pip: 24.3.1
conda: None
pytest: None
mypy: None
IPython: None
sphinx: None
Activity
keewis commentedon Oct 1, 2026
discussion on the attached PR
mohamd764 commentedon Oct 14, 2026
Confirmed on xarray 2026.9.0 (Linux, Python 3.13.5, numpy 2.x) with your MVCE:
da.time.values[:2]prints correctly (2023-01-01T00:00:00...).print(da)raisesValueError: Unknown format code 'g' for object of type 'str'.The failure is in
RangeIndex.__repr__/_repr_inline_, which formatsstart/stop/stepwith:.3g. That works for floats, but datetime64/timedelta64values stringify first, so thegformat rejects them.A small fix is to branch the format: keep
:.3gfor real numbers, and otherwise use plain{self.start}/{self.stop}/{self.step}(ornp.datetime_data-aware formatting). That unblocks printing a lazy datetimeRangeIndexwithout materializing the labels.d-chambers commentedon Oct 14, 2026
@mohamd764 ,
Yes that is exactly what #11559 does