Selecting a relative-time range breaks patch materialization

[d-chambers]

Description

Selecting a range on a relative (timedelta64) coordinate returns the right rows, but materializing a patch from the result raises TypeError.

_canonical_range (dascore/io/index/catalog.py) means to treat only numeric bounds as a canonical-SI range — its fallback branch is commented "datetimes, strings: not a numeric range". But numpy makes np.timedelta64 a subclass of np.signedinteger:

np.timedelta64.__mro__
# (timedelta64, signedinteger, integer, number, generic, object)

so a timedelta bound satisfies isinstance(bound, int | float | np.integer | np.floating), takes the numeric branch, and hits float(bound) — which raises, since float(np.timedelta64(1, "s")) is itself a TypeError. Absolute times are np.datetime64, which is not an integer subclass, so they take the intended fallback and are unaffected.

Everything else about relative-time patches works: len, get_contents(), spool[0], iteration, and chunk(time=...) all behave, and the coord envelope is stored and presented as timedeltas.

Example

import numpy as np
import dascore as dc

patch = dc.get_example_patch()
coord = patch.get_coord("time")
rel = patch.update_coords(time=coord.values - coord.min())  # relative time axis

spool = dc.spool([rel]).select(time=(np.timedelta64(1, "s"), np.timedelta64(3, "s")))
len(spool)   # 1 -- the select itself is fine
spool[0]     # TypeError: float() argument must be a string or a real number,
             # not 'datetime.timedelta'

Expected behavior

A relative range should pass through as a non-numeric range (the fallback the code already intends), so the selected patch materializes like any other. Excluding np.timedelta64 from the numeric test — or checking np.datetime64 | np.timedelta64 before it — appears sufficient.

Versions

• OS: Ubuntu 24.04 (Linux 6.8.0)
• DASCore Version: 0.1.20.dev56 (dev, 6a23ffc)
• Python Version: 3.13.7

[d-chambers]

Two related notes while fixing this:

• typed_value in dascore/io/index/ingest.py already gets this right — it checks np.datetime64 and np.timedelta64 explicitly before the numeric branch, so attrs classify as time/dur correctly. The fix makes _canonical_range consistent with that ordering.
• The same quirk has a milder instance in _validate_sample_values (dascore/utils/misc.py): a timedelta bound passes its isinstance(v, int | np.integer) check, so patch.select(time=(1s, 3s), samples=True) fails later with TypeError: slice indices must be integers instead of the intended ParameterError: When samples=True, values must be integers. Not a crash on valid input, just a worse error message; left out of the fix PR to keep it focused.