tests.unit.test_arrow: test_series_from_arrow[time-nanoseconds-arrow-from-string] failed

[flaky-bot]

This test failed!

To configure my behavior, see the Flaky Bot documentation.

If I'm commenting on this issue too often, add the flakybot: quiet label and
I will stop commenting.

---

commit: 0a3cb48
buildURL: Build Status, Sponge
status: failed

Test output

pyarrow_array = 
[
  00:00:00.000000000,
  12:30:15.123456789,
  23:59:59.999999999
]
expected = 0           00:00:00
1    12:30:14.998902
2    23:59:58.999272
dtype: dbtime
@pytest.mark.parametrize(
    ["expected", "pyarrow_array"],
    SERIES_ARRAYS_DEFAULT_TYPES + SERIES_ARRAYS_CUSTOM_ARROW_TYPES,
)
def test_series_from_arrow(pyarrow_array: pyarrow.Array, expected: pandas.Series):
    # Convert to RecordBatch because types_mapper argument is ignored when
    # using a pyarrow.Array. https://issues.apache.org/jira/browse/ARROW-9664
    record_batch = pyarrow.RecordBatch.from_arrays([pyarrow_array], ["test_col"])
    dataframe = record_batch.to_pandas(date_as_object=False, types_mapper=types_mapper)
    series = dataframe["test_col"]


  pandas.testing.assert_series_equal(series, expected, check_names=False)


tests/unit/test_arrow.py:272:

.nox/unit_prerelease/lib/python3.10/site-packages/pandas/_testing/asserters.py:851: in assert_extension_array_equal

_testing.assert_almost_equal(

pandas/_libs/testing.pyx:52: in pandas._libs.testing.assert_almost_equal

???


???

E   AssertionError: ExtensionArray are different

E

E   ExtensionArray values are different (66.66667 %)

E   [index]: [0, 1, 2]

E   [left]:  [00:00:00, 12:30:15.123456, 23:59:59.999999]

E   [right]: [00:00:00, 12:30:14.998902, 23:59:58.999272]

pandas/_libs/testing.pyx:167: AssertionError

[flaky-bot]

Looks like this issue is flaky. 😟

I'm going to leave this open and stop commenting.

A human should fix and close this.

---

When run at the same commit (0a3cb48), this test passed in one build (Build Status, Sponge) and failed in another build (Build Status, Sponge).

[flaky-bot]

Looks like this issue is flaky. 😟

I'm going to leave this open and stop commenting.

A human should fix and close this.

---

When run at the same commit (0a3cb48), this test passed in one build (Build Status, Sponge) and failed in another build (Build Status, Sponge).

[parthea]

Closing as obsolete

[flaky-bot]

Oops! Looks like this issue is still flaky. It failed again. 😬

I reopened the issue, but a human will need to close it again.

---

commit: 508564f
buildURL: Build Status, Sponge
status: failed

Test output

pyarrow_array = 
[
  00:00:00.000000000,
  12:30:15.123456789,
  23:59:59.999999999
]
expected = 0           00:00:00
1    12:30:14.998902
2    23:59:58.999272
dtype: dbtime
@pytest.mark.parametrize(
    ["expected", "pyarrow_array"],
    SERIES_ARRAYS_DEFAULT_TYPES + SERIES_ARRAYS_CUSTOM_ARROW_TYPES,
)
def test_series_from_arrow(pyarrow_array: pyarrow.Array, expected: pandas.Series):
    # Convert to RecordBatch because types_mapper argument is ignored when
    # using a pyarrow.Array. https://issues.apache.org/jira/browse/ARROW-9664
    record_batch = pyarrow.RecordBatch.from_arrays([pyarrow_array], ["test_col"])
    dataframe = record_batch.to_pandas(date_as_object=False, types_mapper=types_mapper)
    series = dataframe["test_col"]


  pandas.testing.assert_series_equal(series, expected, check_names=False)


tests/unit/test_arrow.py:272:

.nox/unit_prerelease/lib/python3.10/site-packages/pandas/_testing/asserters.py:852: in assert_extension_array_equal

_testing.assert_almost_equal(

pandas/_libs/testing.pyx:52: in pandas._libs.testing.assert_almost_equal

???


???

E   AssertionError: ExtensionArray are different

E

E   ExtensionArray values are different (66.66667 %)

E   [index]: [0, 1, 2]

E   [left]:  [00:00:00, 12:30:15.123456, 23:59:59.999999]

E   [right]: [00:00:00, 12:30:14.998902, 23:59:58.999272]

pandas/_libs/testing.pyx:167: AssertionError

[chalmerlowe]

Based on conversation in the pandas github issue tracker, the root cause of these failing tests appears to be that the pandas system is trying to store too large a number in an int32 memory location. The bug has been added to the pandas 1.5 milestone (pandas is currently at 1.5.0 release candidate stage)

See:
pandas-dev/pandas#48255