pandas-dev/pandas · error · ValueError

cannot supply both a tz and a timezone-naive dtype (i.e. dat

Error message

cannot supply both a tz and a timezone-naive dtype (i.e. datetime64[ns])

What it means

Raised by _validate_tz_from_dtype when a tz= argument is supplied alongside a tz-naive numpy datetime dtype (datetime64[ns]) and they conflict. The dtype declares 'no tz' while tz asks for one; pandas treats that as contradictory input. ValueError.

Source

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

            except TypeError:
                # Things like `datetime64[ns]`, which is OK for the
                # constructors, but also nonsense, which should be validated
                # but not by us. We *do* allow non-existent tz errors to
                # go through
                pass
        dtz = getattr(dtype, "tz", None)
        if dtz is not None:
            if tz is not None and not timezones.tz_compare(tz, dtz):
                raise ValueError("cannot supply both a tz and a dtype with a tz")
            if explicit_tz_none:
                raise ValueError("Cannot pass both a timezone-aware dtype and tz=None")
            tz = dtz

        if tz is not None and lib.is_np_dtype(dtype, "M"):
            # We also need to check for the case where the user passed a
            #  tz-naive dtype (i.e. datetime64[ns])
            if tz is not None and not timezones.tz_compare(tz, dtz):
                raise ValueError(
                    "cannot supply both a tz and a "
                    "timezone-naive dtype (i.e. datetime64[ns])"
                )

    return tz


def _infer_tz_from_endpoints(
    start: Timestamp, end: Timestamp, tz: tzinfo | None
) -> tzinfo | None:
    """
    If a timezone is not explicitly given via `tz`, see if one can
    be inferred from the `start` and `end` endpoints.  If more than one
    of these inputs provides a timezone, require that they all agree.

    Parameters
    ----------
    start : Timestamp

View on GitHub (pinned to 71959b8cb9)

Solutions

1. Drop the dtype and just pass tz=, letting pandas build the aware dtype.
2. Or change the dtype to a tz-aware form like 'datetime64[ns, UTC]' and omit tz=.
3. Avoid hardcoding tz-naive dtypes in code that also accepts a tz argument.

Example fix

# before
pd.DatetimeIndex(data, dtype='datetime64[ns]', tz='UTC')
# after
pd.DatetimeIndex(data, tz='UTC')

def resolve_tz(dtype=None, tz=None):
    is_naive_dt = isinstance(dtype, np.dtype) and dtype.kind == 'M' and getattr(dtype, 'tz', None) is None
    if is_naive_dt and tz is not None:
        raise ValueError('tz-naive dtype conflicts with tz= argument')
    return tz

When it happens

Trigger: pd.DatetimeIndex(data, dtype='datetime64[ns]', tz='UTC'); passing a plain datetime64[ns] dtype plus a tz to astype or a constructor.

Common situations: Helper that always sets dtype='datetime64[ns]' then also forwards a tz kwarg; copy-pasted dtype that should have been a DatetimeTZDtype string.

Related errors

• cannot supply both a tz and a dtype with a tz
• Cannot pass both a timezone-aware dtype and tz=None
• Cannot compare tz-naive and tz-aware datetime-like objects.
• Cannot compare tz-naive and tz-aware datetime-like objects
• Cannot convert tz-naive timestamps, use tz_localize to local

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