BUG: fix to_timestamp out_of_bounds

doc/source/whatsnew/v0.25.1.rst

@@ -32,7 +32,7 @@ Categorical
 Datetimelike
 ^^^^^^^^^^^^
 - Bug in :func:`to_datetime` where passing a timezone-naive :class:`DatetimeArray` or :class:`DatetimeIndex` and ``utc=True`` would incorrectly return a timezone-naive result (:issue:`27733`)
--
+- Bug in :meth:`Period.to_timestamp` where a :class:`Period` outside the :class:`Timestamp` implementation bounds (roughly 1677-09-21 to 2262-04-11) would return an incorrect :class:`Timestamp` instead of raising ``OutOfBoundsDatetime`` (:issue:`19643`)
 -
 -
 

pandas/_libs/tslibs/period.pyx

@@ -21,7 +21,8 @@ PyDateTime_IMPORT
 
 from pandas._libs.tslibs.np_datetime cimport (
     npy_datetimestruct, dtstruct_to_dt64, dt64_to_dtstruct,
-    pandas_datetime_to_datetimestruct, NPY_DATETIMEUNIT, NPY_FR_D)
+    pandas_datetime_to_datetimestruct, check_dts_bounds,
+    NPY_DATETIMEUNIT, NPY_FR_D)
 
 cdef extern from "src/datetime/np_datetime.h":
     int64_t npy_datetimestruct_to_datetime(NPY_DATETIMEUNIT fr,
@@ -1011,7 +1012,7 @@ def dt64arr_to_periodarr(int64_t[:] dtarr, int freq, tz=None):
 
 @cython.wraparound(False)
 @cython.boundscheck(False)
-def periodarr_to_dt64arr(int64_t[:] periodarr, int freq):
+def periodarr_to_dt64arr(const int64_t[:] periodarr, int freq):
     """
     Convert array to datetime64 values from a set of ordinals corresponding to
     periods per period convention.
@@ -1024,9 +1025,8 @@ def periodarr_to_dt64arr(int64_t[:] periodarr, int freq):
 
     out = np.empty(l, dtype='i8')
 
-    with nogil:
-        for i in range(l):
-            out[i] = period_ordinal_to_dt64(periodarr[i], freq)
+    for i in range(l):
+        out[i] = period_ordinal_to_dt64(periodarr[i], freq)
 
     return out.base  # .base to access underlying np.ndarray
 
@@ -1179,14 +1179,15 @@ cpdef int64_t period_ordinal(int y, int m, int d, int h, int min,
     return get_period_ordinal(&dts, freq)
 
 
-cpdef int64_t period_ordinal_to_dt64(int64_t ordinal, int freq) nogil:
+cdef int64_t period_ordinal_to_dt64(int64_t ordinal, int freq) except? -1:
     cdef:
         npy_datetimestruct dts
 
     if ordinal == NPY_NAT:
         return NPY_NAT
 
     get_date_info(ordinal, freq, &dts)
+    check_dts_bounds(&dts)
     return dtstruct_to_dt64(&dts)
 
 

pandas/tests/arrays/test_datetimelike.py

@@ -1,6 +1,8 @@
 import numpy as np
 import pytest
 
+from pandas._libs import OutOfBoundsDatetime
+
 import pandas as pd
 from pandas.core.arrays import DatetimeArray, PeriodArray, TimedeltaArray
 import pandas.util.testing as tm
@@ -615,6 +617,15 @@ def test_to_timestamp(self, how, period_index):
         #  an EA-specific tm.assert_ function
         tm.assert_index_equal(pd.Index(result), pd.Index(expected))
 
+    def test_to_timestamp_out_of_bounds(self):
+        # GH#19643 previously overflowed silently
+        pi = pd.period_range("1500", freq="Y", periods=3)
+        with pytest.raises(OutOfBoundsDatetime):
+            pi.to_timestamp()
+
+        with pytest.raises(OutOfBoundsDatetime):
+            pi._data.to_timestamp()
+
     @pytest.mark.parametrize("propname", PeriodArray._bool_ops)
     def test_bool_properties(self, period_index, propname):
         # in this case _bool_ops is just `is_leap_year`

pandas/tests/scalar/period/test_asfreq.py

@@ -30,11 +30,8 @@ def test_asfreq_near_zero_weekly(self):
         assert week1.asfreq("D", "E") >= per1
         assert week2.asfreq("D", "S") <= per2
 
-    @pytest.mark.xfail(
-        reason="GH#19643 period_helper asfreq functions fail to check for overflows"
-    )
     def test_to_timestamp_out_of_bounds(self):
-        # GH#19643, currently gives Timestamp('1754-08-30 22:43:41.128654848')
+        # GH#19643, used to incorrectly give Timestamp in 1754
         per = Period("0001-01-01", freq="B")
         with pytest.raises(OutOfBoundsDatetime):
             per.to_timestamp()