pydata
FutureWarning: decode_timedelta will default to False rather than None
What happened?
I followed some tutorial/generated code to try out accessing weather forecast data. It does seem to work but prints a long warning message in the middle of my program output:
C:\Users...\AppData\Local\Packages\PythonSoftwareFoundation.Python.3.13_qbz5n2kfra8p0\LocalCache\local-packages\Python313\site-packages\cfgrib\xarray_plugin.py:131: FutureWarning: In a future version of xarray decode_timedelta will default to False rather than None. To silence this warning, set decode_timedelta to True, False, or a 'CFTimedeltaCoder' instance.
What did you expect to happen?
Nothing?
Minimal Complete Verifiable Example
import os
import bz2
import requests
import xarray as xr
import numpy as np
import pandas as pd
from scipy.interpolate import griddata
# Parameter
run_date = "20250601"
run_hour = "09"
forecast_hour = "001"
base_url = f"https://opendata.dwd.de/weather/nwp/icon-d2/grib/{run_hour}/t_2m/"
filename = f"icon-d2_germany_regular-lat-lon_single-level_{run_date}{run_hour}_{forecast_hour}_2d_t_2m.grib2.bz2"
grib_bz2_url = base_url + filename
grib_outfile = "t2m.grib2"
# Koordinaten der Orte (Breite, Länge)
locations = {
"Berlin": (52.52, 13.405),
"München": (48.137, 11.575),
}
# Download und Dekomprimierung
def download_grib_bz2(url, outfile):
print(f"Lade herunter: {url}")
r = requests.get(url)
if r.status_code != 200:
raise Exception(f"Fehler beim Download: {r.status_code}")
decompressed = bz2.decompress(r.content)
with open(outfile, "wb") as f:
f.write(decompressed)
print(f"Gespeichert als: {outfile}")
# Extrahiere Temperatur für Koordinaten
def extract_temperature(gribfile, coords):
ds = xr.open_dataset(gribfile, engine="cfgrib")
lat = ds.latitude.values
lon = ds.longitude.values
temp = ds.t2m.values - 273.15 # Kelvin -> Celsius
lon_grid, lat_grid = np.meshgrid(lon, lat)
flat_points = np.column_stack((lat_grid.ravel(), lon_grid.ravel()))
flat_values = temp.ravel()
results = {}
for city, (la, lo) in coords.items():
val = griddata(flat_points, flat_values, (la, lo), method='linear')
results[city] = round(float(val), 2)
return results
# Ausführen
download_grib_bz2(grib_bz2_url, grib_outfile)
temperatures = extract_temperature(grib_outfile, locations)
df = pd.DataFrame.from_dict(temperatures, orient="index", columns=["Temp (°C)"])
print(df)
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.
- [ ] 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.
- [x] Recent environment — the issue occurs with the latest version of xarray and its dependencies.
Relevant log output
Anything else we need to know?
I have no idea whether the code is minimal. I don't know where the issue comes from so I cannot trim it down.
It should run as-is. Maybe the PIP packages xarray, requests, scipy, cfgrib need to be installed.
Python version is 3.13.3 on Windows 11. Nothing newer is available now.
Environment
xarray: 2025.4.0 pandas: 2.2.3 numpy: 2.2.6 scipy: 1.15.3 netCDF4: None pydap: None h5netcdf: None h5py: None zarr: None cftime: 1.6.4.post1 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: 25.1.1 conda: None pytest: None mypy: None IPython: None sphinx: None
I have no idea whether the code is minimal. I don't know where the issue comes from so I cannot trim it down.
check out https://stackoverflow.com/help/minimal-reproducible-example
The warning stems from the fact that the file contains a variable that contains a timedelta-like units attribute—in this case step has a units attribute of "hours". It is emitted during the xr.open_dataset call.
xarray.Dataset {
dimensions:
latitude = 746 ;
longitude = 1215 ;
variables:
int64 time() ;
time:long_name = initial time of forecast ;
time:units = seconds since 1970-01-01T00:00:00 ;
time:calendar = proleptic_gregorian ;
time:standard_name = forecast_reference_time ;
float64 step() ;
step:long_name = time since forecast_reference_time ;
step:units = hours ;
step:standard_name = forecast_period ;
float64 heightAboveGround() ;
heightAboveGround:long_name = height above the surface ;
heightAboveGround:units = m ;
heightAboveGround:positive = up ;
heightAboveGround:standard_name = height ;
float64 latitude(latitude) ;
latitude:units = degrees_north ;
latitude:standard_name = latitude ;
latitude:long_name = latitude ;
float64 longitude(longitude) ;
longitude:units = degrees_east ;
longitude:standard_name = longitude ;
longitude:long_name = longitude ;
float64 valid_time() ;
valid_time:units = seconds since 1970-01-01T00:00:00 ;
valid_time:calendar = proleptic_gregorian ;
valid_time:standard_name = time ;
valid_time:long_name = time ;
float32 t2m(latitude, longitude) ;
t2m:GRIB_paramId = 167 ;
t2m:GRIB_dataType = fc ;
t2m:GRIB_numberOfPoints = 906390 ;
t2m:GRIB_typeOfLevel = heightAboveGround ;
t2m:GRIB_stepUnits = 1 ;
t2m:GRIB_stepType = instant ;
t2m:GRIB_gridType = regular_ll ;
t2m:GRIB_uvRelativeToGrid = 0 ;
t2m:GRIB_NV = 0 ;
t2m:GRIB_Nx = 1215 ;
t2m:GRIB_Ny = 746 ;
t2m:GRIB_cfName = air_temperature ;
t2m:GRIB_cfVarName = t2m ;
t2m:GRIB_gridDefinitionDescription = Latitude/longitude ;
t2m:GRIB_iDirectionIncrementInDegrees = 0.02 ;
t2m:GRIB_iScansNegatively = 0 ;
t2m:GRIB_jDirectionIncrementInDegrees = 0.02 ;
t2m:GRIB_jPointsAreConsecutive = 0 ;
t2m:GRIB_jScansPositively = 1 ;
t2m:GRIB_latitudeOfFirstGridPointInDegrees = 43.18 ;
t2m:GRIB_latitudeOfLastGridPointInDegrees = 58.08 ;
t2m:GRIB_longitudeOfFirstGridPointInDegrees = 356.06 ;
t2m:GRIB_longitudeOfLastGridPointInDegrees = 20.34 ;
t2m:GRIB_missingValue = 3.4028234663852886e+38 ;
t2m:GRIB_name = 2 metre temperature ;
t2m:GRIB_shortName = 2t ;
t2m:GRIB_units = K ;
t2m:long_name = 2 metre temperature ;
t2m:units = K ;
t2m:standard_name = air_temperature ;
t2m:coordinates = time step heightAboveGround latitude longitude valid_time ;
// global attributes:
:GRIB_edition = 2 ;
:GRIB_centre = edzw ;
:GRIB_centreDescription = Offenbach ;
:GRIB_subCentre = 255 ;
:Conventions = CF-1.7 ;
:institution = Offenbach ;
We are in the process of changing xarray's default behavior upon opening datasets with these variables. Xarray currently automatically decodes them into np.timedelta64 values, which has been deemed undesirable (https://github.com/pydata/xarray/issues/1621). In the future we are planning to leave these variables alone by default, hence the warning.
In the next version of xarray, the warning will be a bit more informative (though perhaps it could be improved further by calling out at least one variable that triggered the warning):
FutureWarning: In a future version, xarray will not decode timedelta values based on the presence of a timedelta-like units attribute by default. Instead it will rely on the presence of a timedelta64 dtype attribute, which is now xarray's default way of encoding timedelta64 values. To continue decoding timedeltas based on the presence of a timedelta-like units attribute, users will need to explicitly opt-in by passing True or CFTimedeltaCoder(decode_via_units=True) to decode_timedelta. To silence this warning, set decode_timedelta to True, False, or a 'CFTimedeltaCoder' instance.
If the dtype of this particular variable is unimportant, you are free to ignore the warning. You can also silence the warning by setting decode_timedelta to something other than None in xr.open_dataset. For example, if you would like to persist the existing default behavior you could use xr.open_dataset(..., decode_timedelta=True).
@ygoe Please let us know whether @spencerkclark's comment helps in your case or if we can improve the warning message beyond his suggestion.
Yes, the suggestion in the last sentence resolved the issue. But then I stopped using it again because the whole weather forecast data thing grew over my head very quickly. Met offices make it really hard to use their publicly provided data. ☹️ So I won't be able to observe the future behaviour.