ValueError: conflicting sizes for dimension np.str_('time')

[digital-idiot]

Below is the code snippet to reproduce the issue

import xarray as xr
import rioxarray as rxr

src_path = "TerraClimate_Data.nc"

xds = xr.open_dataset(src_path)
rds = rxr.open_rasterio(src_path)

Error:

----> 7 rds = rxr.open_rasterio(src_path)
ValueError: conflicting sizes for dimension np.str_('time'): length 372 on the data but length 12 on coordinate np.str_('time')

printing xds I get:

In [4]: print(xds)
<xarray.Dataset> Size: 666GB
Dimensions:  (x: 8640, y: 4320, time: 372)
Coordinates:
  * x        (x) float64 69kB -180.0 -179.9 -179.9 -179.9 ... 179.9 179.9 180.0
  * y        (y) float64 35kB 89.98 89.94 89.9 89.85 ... -89.9 -89.94 -89.98
  * time     (time) datetime64[ns] 3kB 1994-01-01 1994-02-01 ... 2024-12-01
Data variables:
    crs      int64 8B ...
    pet      (time, y, x) float64 111GB ...
    ppt      (time, y, x) float64 111GB ...
    tmax     (time, y, x) float64 111GB ...
    tmin     (time, y, x) float64 111GB ...
    vap      (time, y, x) float64 111GB ...
    vpd      (time, y, x) float64 111GB ...

If I understand correctly this does not seem like 4D data so what might be the issue here?

[ungaaaabungaaa]

Your printed dataset has three dimensions (time, y, x); six data variables do not make it a six- or four-dimensional array. Each listed climate variable is (time, y, x).

Since xr.open_dataset() already opens it, you can use rioxarray's accessor on that dataset without reopening it through open_rasterio:

import xarray as xr
import rioxarray  # registers the .rio accessor

with xr.open_dataset("TerraClimate_Data.nc", decode_coords="all") as ds:
    pet = ds["pet"]
    print(pet.sizes)
    print(pet.rio.crs)
    print(pet.rio.bounds())

This is a documented loading path: rioxarray with xarray-opened NetCDF. import rioxarray registers .rio; decode_coords="all" makes CF grid-mapping variables available as coordinates. With your existing x/y dimension names, no rename is needed. If pet.rio.crs is None, establish the correct CRS from the file/source metadata; don't assume one from this example.

The exception describes a different issue: the Rasterio-backed result has 372 time slices but a time-coordinate array of length 12. Those lengths cannot describe the same dimension. The printed xarray output alone does not establish whether that mismatch originates in file metadata, GDAL's interpretation, or a rioxarray/version issue. This loading workaround does not repair or diagnose that mismatch.

Verified with Python 3.14.7 / rioxarray 0.24.0 / xarray 2026.9.0 / Rasterio 1.5.2 (GDAL 3.12.2), using a small synthetic NetCDF written with SciPy 1.18.1. The exact example retained all 372 time coordinates for six variables, with the expected CRS, bounds, and data values. I have not tested your original file or reproduced its 372-versus-12 exception. Prepared and checked with OpenAI Codex assistance.