pandas-dev/pandas · error · ValueError

Values resolution does not match dtype.

Error message

Values resolution does not match dtype.

What it means

Raised by DatetimeArray._validate_dtype in the tz-naive (np.dtype) branch when the backing numpy values' datetime64 unit does not equal the declared dtype's unit. pandas must keep the stored array and its dtype in lockstep on resolution; a mismatch (e.g. data stored in 's' but dtype claims 'ns') would corrupt every value silently.

Source

Thrown at pandas/core/arrays/datetimes.py:293

    # ndim is inherited from ExtensionArray, must exist to ensure
    #  Timestamp.__richcmp__(DateTimeArray) operates pointwise

    # ensure that operations with numpy arrays defer to our implementation
    __array_priority__ = 1000

    # -----------------------------------------------------------------
    # Constructors

    _dtype: np.dtype[np.datetime64] | DatetimeTZDtype

    @classmethod
    def _validate_dtype(cls, values, dtype):
        # used in TimeLikeOps.__init__
        dtype = _validate_dt64_dtype(dtype)
        _validate_dt64_dtype(values.dtype)
        if isinstance(dtype, np.dtype):
            if values.dtype != dtype:
                raise ValueError("Values resolution does not match dtype.")
        else:
            vunit = np.datetime_data(values.dtype)[0]
            if vunit != dtype.unit:
                raise ValueError("Values resolution does not match dtype.")
        return dtype

    # error: Signature of "_simple_new" incompatible with supertype "NDArrayBacked"
    @classmethod
    def _simple_new(  # type: ignore[override]
        cls,
        values: npt.NDArray[np.datetime64],
        dtype: np.dtype[np.datetime64] | DatetimeTZDtype = DT64NS_DTYPE,
    ) -> Self:
        assert isinstance(values, np.ndarray)
        assert dtype.kind == "M"
        if isinstance(dtype, np.dtype):
            assert dtype == values.dtype
            assert not is_unitless(dtype)

View on GitHub (pinned to 71959b8cb9)

Solutions

1. Use astype_overflowsafe to convert the values to the target unit before wrapping, or rely on the public as_unit.
2. Ensure the dtype passed to the constructor is built from the same unit string as values.dtype (np.datetime_data(values.dtype)[0]).
3. Reconstruct via cls._simple_new only after both agree; prefer cls._from_sequence / pd.to_datetime for user code.

Example fix

# before
arr = np.array(['2020-01-01'], dtype='datetime64[s]')
dti = DatetimeArray._simple_new(arr.view('datetime64[ns]'), dtype=DT64NS_DTYPE)

# after
from pandas.core.arrays.datetimes import DatetimeArray
import pandas.core.dtypes.common as com
arr = np.array(['2020-01-01'], dtype='datetime64[s]')
da = DatetimeArray._from_sequence(arr).as_unit('ns')

vunit = np.datetime_data(values.dtype)[0]
if isinstance(dtype, np.dtype):
    assert values.dtype == dtype, f'{values.dtype} vs {dtype}'

try:
    DatetimeArray._simple_new(values, dtype=dtype)
except ValueError as e:
    if 'resolution does not match' in str(e):
        values = astype_overflowsafe(values, dtype)
        DatetimeArray._simple_new(values, dtype=dtype)
    else: raise

When it happens

Trigger: Internal construction path where raw datetime64 arrays of one unit are paired with a dtype of another (e.g. low-level _simple_new misuse, or a custom EA bridge). Not normally user-facing unless bypassing public constructors.

Common situations: Custom ExtensionArray subclasses that build DatetimeArray internals; interop code that re-wraps numpy arrays after a unit-changing view; bugs in library bridges (Arrow, Dask) that re-stitch arrays to dtypes.

Related errors

• value should be a '{self._scalar_type.__name__}', 'NaT', or
• Supported units are 's', 'ms', 'us', 'ns'
• {dtype=} does not have a resolution.
• dtype {data.dtype} cannot be converted to datetime64[ns]
• Passing PeriodDtype data is invalid. Use `data.to_timestamp(

AI-assisted analysis of pandas-dev/pandas@71959b8cb9 (2026-08-07). Data as JSON: /api/errors/852f558dccf93a75. Report an issue: GitHub.