document limitations of cftime arithmetics #10653
Conversation
for more information, see https://pre-commit.ci
|
I have a code example that inentionally should fail, i used the notation for that part. |
|
I'm not sure why the readthedocs fails, my local build seems to work. |
There was a problem hiding this comment.
Thanks @larsbuntemeyer! It would be nice to get this working cleanly someday, especially now that xarray supports coarser resolution np.timedelta64 values.
You could also consider including a more verbose, but also more robust, workaround that adds the two DataArrays via apply_ufunc:
def add_cftime_and_timedelta64(cftime_da, timedelta64_da, join="inner"):
def func(cftime_array, timedelta64_array):
shape = cftime_array.shape
cftime_array = cftime_array.ravel()
timedelta64_array = timedelta64_array.ravel()
timedelta_array = pd.to_timedelta(timedelta64_array).to_pytimedelta()
return (cftime_array + timedelta_array).reshape(shape)
return xr.apply_ufunc(
func,
cftime_da,
timedelta64_da,
dask="parallelized",
output_dtypes=[cftime_da.dtype],
join=join
)This function has the advantage that it preserves the coordinate alignment, as well as multi-dimensional and dask compatibility features of xarray.
| import cftime | ||
|
|
||
| time = xr.DataArray( | ||
| xr.cftime_range("2000", periods=3, freq="MS", calendar="noleap"), |
There was a problem hiding this comment.
I think this should fix the doc build—xarray.cftime_range has been deprecated since it is redundant as public API, so using it emits a warning:
| xr.cftime_range("2000", periods=3, freq="MS", calendar="noleap"), | |
| xr.date_range("2000", periods=3, freq="MS", calendar="noleap"), |
whats-new.rst