DOC: fill in issue references

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

Author: jbrockmendel

doc/source/whatsnew/v3.1.0.rst

@@ -118,7 +118,7 @@ See :ref:`install.dependencies` and :ref:`install.optional_dependencies` for mor
 Other API changes
 ^^^^^^^^^^^^^^^^^
 - :attr:`Index.values` and :attr:`Index.array` now return read-only arrays for all dtypes, so an :class:`Index` can no longer be silently corrupted by mutating the returned array in place (previously this left the Index displaying the new value while lookups still used the old one) (:issue:`38547`)
-- :class:`Timestamp` with a non-zero ``nanosecond`` argument now stores the result in nanosecond resolution regardless of ``unit`` and of the input's own resolution, so values too far from the epoch to be held in nanoseconds raise :class:`OutOfBoundsDatetime` where the keyword was previously ignored (:issue:`XXXXX`)
+- :class:`Timestamp` with a non-zero ``nanosecond`` argument now stores the result in nanosecond resolution regardless of ``unit`` and of the input's own resolution, so values too far from the epoch to be held in nanoseconds raise :class:`OutOfBoundsDatetime` where the keyword was previously ignored (:issue:`66533`)
 - :func:`infer_freq` on quarter-start data now reports the equivalent anchor from the first calendar quarter, e.g. ``QS-JAN`` instead of ``QS-OCT`` (:issue:`36939`)
 - :func:`testing.assert_frame_equal` with ``check_freq=True`` now also checks the ``freq`` of :class:`DatetimeIndex` and :class:`TimedeltaIndex` *columns*; previously only the ``freq`` of the index was checked (:issue:`51920`)
 - :func:`testing.assert_series_equal` with ``check_index=False`` no longer checks the ``freq`` attribute of a :class:`DatetimeIndex` or :class:`TimedeltaIndex`, as ``freq`` is an attribute of the index (:issue:`51920`)
@@ -338,8 +338,8 @@ Datetimelike
 - Bug in :class:`Timestamp` constructor and :meth:`Timestamp.replace` where a value landing exactly on the ``NaT`` sentinel — whether from a ``nanosecond`` or ``microsecond`` argument or from shifting a timezone-aware wall time to UTC — silently produced ``NaT`` (or a :class:`Timestamp` that reported itself as non-null but read back as ``NaT`` once placed in a :class:`Series`) instead of raising :class:`OutOfBoundsDatetime` (:issue:`66510`)
 - Bug in :class:`Timestamp` constructor and :meth:`Timestamp.replace` where shifting a timezone-aware value to UTC past the representable range raised a raw ``OverflowError`` instead of :class:`OutOfBoundsDatetime`, e.g. ``Timestamp.max.replace(tzinfo=timezone(timedelta(hours=-9)))`` (:issue:`66510`)
 - Bug in :class:`Timestamp` constructor where passing ``np.str_`` objects would fail in Cython string parsing (:issue:`48974`)
-- Bug in :class:`Timestamp` constructor where the ``nanosecond`` keyword was silently ignored unless the first argument was a ``datetime`` or :class:`Timestamp`; it is now also honored for :class:`numpy.datetime64`, ``date``, ``int``, and ``float`` input, in each case overwriting (not adding to) the sub-microsecond portion of the input (:issue:`XXXXX`)
 - Bug in :class:`Timestamp` constructor where strings with a negative year of fewer than 4 digits (e.g. ``"-111-01-01"``) silently dropped the leading ``"-"`` and were parsed as a positive year; BC dates with 1-4 digit years now parse correctly, matching :class:`numpy.datetime64` (:issue:`55954`)
+- Bug in :class:`Timestamp` constructor where the ``nanosecond`` keyword was silently ignored unless the first argument was a ``datetime`` or :class:`Timestamp`; it is now also honored for :class:`numpy.datetime64`, ``date``, ``int``, and ``float`` input, in each case overwriting (not adding to) the sub-microsecond portion of the input (:issue:`66533`)
 - Bug in :class:`Timestamp` constructor, :class:`Timedelta` constructor, :func:`to_datetime`, and :func:`to_timedelta` with non-round ``float`` input and ``unit`` failing to raise when the value is just outside the representable bounds (:issue:`57366`)
 - Bug in :func:`api.types.infer_dtype` returning ``"date"`` or ``"mixed"`` instead of ``"datetime"`` / ``"timedelta"`` for lists of :class:`Timestamp`/:class:`Timedelta` values mixed with ``pd.NA`` (:issue:`53023`)
 - Bug in :func:`date_range` where ``inclusive="left"`` and ``inclusive="right"`` returned a single-element result instead of empty when ``start`` equals ``end`` (:issue:`55293`)

pandas/tests/scalar/timestamp/test_constructors.py

@@ -1206,7 +1206,7 @@ def test_timestamp_iso8601_offset_out_of_bounds(tz):
     ],
 )
 def test_timestamp_constructor_nanosecond_kwarg(ts_input, kwargs):
-    # GH#XXXXX nanosecond was silently dropped for everything but pydatetime.
+    # GH#66533 nanosecond was silently dropped for everything but pydatetime.
     #  The inputs carrying 123ns also pin down "set", not "add", semantics.
     result = Timestamp(ts_input, nanosecond=5, **kwargs)
     assert result.nanosecond == 5
@@ -1215,7 +1215,7 @@ def test_timestamp_constructor_nanosecond_kwarg(ts_input, kwargs):
 
 
 def test_timestamp_constructor_nanosecond_kwarg_float():
-    # GH#XXXXX non-integral float input; the 456ns pins down set-not-add, and
+    # GH#66533 non-integral float input; the 456ns pins down set-not-add, and
     #  the microseconds must survive the overwrite
     result = Timestamp(0.000123456, unit="s", nanosecond=5)
     assert result == Timestamp("1970-01-01 00:00:00.000123") + Timedelta(nanoseconds=5)
@@ -1231,7 +1231,7 @@ def test_timestamp_constructor_nanosecond_kwarg_float():
     ],
 )
 def test_timestamp_constructor_nanosecond_kwarg_pre_epoch(ts_input, kwargs):
-    # GH#XXXXX -1ns has 999 in the sub-microsecond field, so adding rather
+    # GH#66533 -1ns has 999 in the sub-microsecond field, so adding rather
     #  than setting would carry into the microseconds
     result = Timestamp(ts_input, nanosecond=5, **kwargs)
     assert result == Timestamp("1969-12-31 23:59:59.999999") + Timedelta(nanoseconds=5)
@@ -1247,7 +1247,7 @@ def test_timestamp_constructor_nanosecond_kwarg_pre_epoch(ts_input, kwargs):
     ],
 )
 def test_timestamp_constructor_nanosecond_kwarg_preserves_microsecond(ts_input):
-    # GH#XXXXX only the sub-microsecond field is overwritten
+    # GH#66533 only the sub-microsecond field is overwritten
     result = Timestamp(ts_input, nanosecond=5)
     assert result.microsecond == 123
     assert result.nanosecond == 5
@@ -1262,7 +1262,7 @@ def test_timestamp_constructor_nanosecond_kwarg_preserves_microsecond(ts_input):
     ],
 )
 def test_timestamp_constructor_nanosecond_zero_not_passed(ts_input, kwargs):
-    # GH#XXXXX nanosecond=0 means "not passed", so the input's own
+    # GH#66533 nanosecond=0 means "not passed", so the input's own
     #  resolution is retained
     result = Timestamp(ts_input, nanosecond=0, **kwargs)
     assert result.unit == "s"
@@ -1277,15 +1277,15 @@ def test_timestamp_constructor_nanosecond_zero_not_passed(ts_input, kwargs):
     ],
 )
 def test_timestamp_constructor_nanosecond_zero_keeps_sub_microsecond(ts_input):
-    # GH#XXXXX "not passed" is the *only* meaning of nanosecond=0 -- it does not
+    # GH#66533 "not passed" is the *only* meaning of nanosecond=0 -- it does not
     #  zero an existing sub-microsecond value, matching the long-standing
     #  pydatetime behaviour.  A non-zero nanosecond does overwrite.
     assert Timestamp(ts_input).nanosecond == 123
     assert Timestamp(ts_input, nanosecond=0).nanosecond == 123
 
 
 def test_timestamp_constructor_nanosecond_kwarg_tz_epoch_int():
-    # GH#XXXXX an epoch integer is UTC-based, so tz converts rather than
+    # GH#66533 an epoch integer is UTC-based, so tz converts rather than
     #  localizes
     result = Timestamp(0, unit="s", nanosecond=5, tz="US/Pacific")
     assert result._value == 5
@@ -1302,7 +1302,7 @@ def test_timestamp_constructor_nanosecond_kwarg_tz_epoch_int():
     ],
 )
 def test_timestamp_constructor_nanosecond_kwarg_tz_wall(ts_input):
-    # GH#XXXXX datetime64/date/datetime are wall times, so tz localizes
+    # GH#66533 datetime64/date/datetime are wall times, so tz localizes
     result = Timestamp(ts_input, nanosecond=5, tz="US/Pacific")
     assert result._value == 8 * 3600 * 10**9 + 5
     assert result.nanosecond == 5
@@ -1339,7 +1339,7 @@ def test_timestamp_constructor_nanosecond_kwarg_tz_wall(ts_input):
 def test_timestamp_constructor_nanosecond_kwarg_out_of_bounds(
     ts_input, kwargs, nanosecond, msg
 ):
-    # GH#XXXXX
+    # GH#66533
     with pytest.raises(OutOfBoundsDatetime, match=msg):
         Timestamp(ts_input, nanosecond=nanosecond, **kwargs)