Skip to content

Conversation

@pavansai018
Copy link

Summary

Constructing a Period from a Timestamp whose underlying integer becomes out-of-range when interpreted at a higher-resolution frequency (e.g., treating Timestamp.min.value as microseconds) previously triggered a low-level OverflowError inside get_period_ordinal, which is declared noexcept. This resulted in an unraisable exception and Period(...) silently returning an incorrect ordinal instead of raising OutOfBoundsDatetime.

What this PR changes

A new internal helper _period_ordinal_safe(...) is introduced. It mirrors the logic of get_period_ordinal but is allowed to raise Python exceptions. cpdef period_ordinal(...), which feeds the Python-facing Period(...) API, now delegates to this safe helper.

This ensures:

  • low-level period arithmetic and internal callers continue using the original get_period_ordinal unchanged,
  • Python-facing constructions such as Period(Timestamp, "us") correctly raise OutOfBoundsDatetime when the timestamp cannot be represented at the target frequency,
  • no C-level OverflowError leaks into pytest as an unraisable exception.

Test

The regression test:

ts = pd.Timestamp(pd.Timestamp.min.value, unit="us")
with pytest.raises(OutOfBoundsDatetime):
    pd.Period(ts, freq="us")

Fixes #63278

@jbrockmendel
Copy link
Member

We don't want this to raise.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

BUG: Period(distant_past_timestamp, freq="us")

2 participants