Summary

tests/test_plotly_utils/validators/test_pandas_series_input.py has two tests that assert the dtype of a validated datetime64 array against the hardcoded little-endian literal "<M8[ns]":

def test_data_array_validator_dates_series(...):
    res = data_array_validator.validate_coerce(datetime_pandas)
    ...
    assert res.dtype == "<M8[ns]"

def test_data_array_validator_dates_dataframe(...):
    res = data_array_validator.validate_coerce(df)
    ...
    assert res.dtype == "<M8[ns]"

On big-endian platforms (e.g. z/OS on s390x), numpy's datetime64[ns] arrays naturally resolve to big-endian (native) byte order through this conversion path, so res.dtype ends up as >M8[ns], not <M8[ns] — and these two tests fail, even though DataArrayValidator's actual behavior is correct (it preserves/produces the host's native dtype, which is what every other dtype check in this file already compares against, e.g. assert res.dtype == numeric_pandas.dtype).

Why this happens

dates_array (the fixture these tests compare values against) is built with an unmarked dtype spec (dtype="datetime64[ns]"), which numpy resolves to the host's native byte order. The validator's output tracks that same native order. So res.dtype always equals dates_array.dtype on any host, but only equals the literal "<M8[ns]" specifically on little-endian hosts.

Suggested fix

Compare against dates_array.dtype instead of the hardcoded literal, consistent with how the other tests in this file already check dtype:

assert res.dtype == dates_array.dtype

I've verified this change is a no-op on little-endian (ran the full test file before/after: 88 passed in both cases), and reasoned through the byte-order mechanism directly (confirmed dates_array.dtype and the validator's output dtype both track host-native order, while the literal does not). I don't have a big-endian machine on hand to literally reproduce the original failure, but the mechanism is straightforward numpy behavior.

I'll open a PR with this fix.