Uh oh!
There was an error while loading. Please reload this page.
Fix Upstream CI NaT issues - #11340
Conversation
Uh oh!
There was an error while loading. Please reload this page.
spencerkclark
left a comment
There was a problem hiding this comment.
Thanks @ianhi—this looks good to me too. I'm pleased to see that upstream change. It might allow us to eventually simplify some of our overflow-related code.
I have not looked much further, but a bisect indicates the non-upstream test failure is a result of pandas-dev/pandas#64379, which doesn't seem like it was intended to be a breaking change.
Uh oh!
There was an error while loading. Please reload this page.
1. Take more care in not generating rectilinear chunk grids on spec version 1 2. update our model for shift-array with rectilinear chunks 3. fix the xarray-upstream-backend-tests issue creation this gets us almost all the way to green. the remaining failures are actualyl xarray failures and are fixed there: pydata/xarray#11340
numpy >= 2.5 deprecates the 'generic' (unitless) datetime64/timedelta64
dtype. Constructing np.datetime64("2000") or np.datetime64("NaT") in the
parametrize list ran during pytest collection, and with
filterwarnings=error the resulting DeprecationWarning aborted collection
of the whole module on the upstream-dev CI. That in turn produced a
malformed pytest report and silently disabled the
issue-from-pytest-log-action auto-issue filer.
Pin the unit explicitly so collection stays clean on numpy nightly.numpy >= 2.5 (numpy/numpy#31378, merged 2026-05-11) turns int64.min * timedelta64 from a silent NaT into a hard OverflowError. The CF time decode path relied on the silent NaT and now raises through _check_date_for_units_since_refdate and _check_timedelta_range, surfacing as `ValueError: unable to decode time units '...'` from decode_cf. Detect the sentinel (and float NaN) up front so the multiplication path only sees real numeric inputs. Regression coverage already exists via the existing int64.min parametrizations of test_cf_timedelta and test_roundtrip_timedelta64_nanosecond_precision.
Illviljan
commented
May 31, 2026
Lots of mypy errors, is it because pip is not installed? |
keewis
left a comment
There was a problem hiding this comment.
I have one question regarding the construction of delta, other wise this looks good to me.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
* Use explicit ns unit for np.datetime64 in test parametrize
numpy >= 2.5 deprecates the 'generic' (unitless) datetime64/timedelta64
dtype. Constructing np.datetime64("2000") or np.datetime64("NaT") in the
parametrize list ran during pytest collection, and with
filterwarnings=error the resulting DeprecationWarning aborted collection
of the whole module on the upstream-dev CI. That in turn produced a
malformed pytest report and silently disabled the
issue-from-pytest-log-action auto-issue filer.
Pin the unit explicitly so collection stays clean on numpy nightly.
* Handle int64 NaT sentinel before timedelta64 multiplication
numpy >= 2.5 (numpy/numpy#31378, merged 2026-05-11) turns
int64.min * timedelta64 from a silent NaT into a hard OverflowError.
The CF time decode path relied on the silent NaT and now raises through
_check_date_for_units_since_refdate and _check_timedelta_range, surfacing
as `ValueError: unable to decode time units '...'` from decode_cf.
Detect the sentinel (and float NaN) up front so the multiplication path
only sees real numeric inputs. Regression coverage already exists via
the existing int64.min parametrizations of test_cf_timedelta and
test_roundtrip_timedelta64_nanosecond_precision.
---------
Co-authored-by: Illviljan <14371165+Illviljan@users.noreply.github.com>
Co-authored-by: Justus Magin <keewis@users.noreply.github.com>
Description
Two separate things:
I ended up consolidating the two methods in code/times by a bit to avoid writing the same fix twice. They had almost exactly the same code path.
cc @dcherian
Checklist
whats-new.rstapi.rstAI Disclosure