DEPR: Deprecate non-ISO date string formats in DatetimeIndex.loc #62991

raghavendranath · 2025-11-05T03:08:54Z

closes BUG: .loc with DateTimeIndex allows day first string for stop in slice, but not start #58302
Tests added and passed if fixing a bug or adding a new feature
All code checks passed.
Added type annotations to new arguments/methods/functions.
Added an entry in the latest doc/source/whatsnew/vX.X.X.rst file if fixing a bug or adding a new feature.

Before:

ser.loc["1/10/2024":"1/14/2024"]      # Returns Jan 10-14
ser.loc["1/10/2024":"14/1/2024"]      # Also returns Jan 10-14
ser.loc["10/1/2024":"14/1/2024"]      # Returns empty

After:

ser.loc["1/10/2024":"1/14/2024"]      # Still returns Jan 10-14 + FutureWarning
ser.loc["2024-01-10":"2024-01-14"]    # Use ISO format instead

There's no way to know if "1/10/2024" is being parsed as MM/DD or DD/MM until you run it. This deprecation pushes users toward ISO format to avoid the confusion.

raghavendranath · 2025-11-09T17:45:06Z

Hi @WillAyd @MarcoGorelli @mroeschke The PR is ready for review whenever you have time. Thanks

WillAyd · 2025-11-10T14:11:01Z

pandas/core/indexes/datetimes.py

    return result


+def _is_iso_format_string(date_str: str) -> bool:


Credit to @stefmolin for the original idea, but I don't think we should try and roll our own regex here if we can avoid it.

I see the standard library provides date.fromisostring, although that is documented to not work with "Reduced Precision" dates:

https://docs.python.org/3/library/datetime.html

Even still I wonder if we can't use that first and only fallback when it fails

Thanks @stefmolin @WillAyd!. Switched to using date.fromisoformat() like you suggested. Added a regex fallback to handle the reduced precision dates (YYYY and YYYY-MM) that fromisoformat doesn't support .

WillAyd · 2025-11-10T14:12:04Z

pandas/tests/groupby/methods/test_value_counts.py

 @pytest.mark.parametrize("bins", [None, [0, 5]], ids=repr)
 @pytest.mark.parametrize("isort", [True, False])
 @pytest.mark.parametrize("normalize, name", [(True, "proportion"), (False, "count")])
+@pytest.mark.filterwarnings(


Why does this test need to filter warnings? It seems unrelated to the change?

When we group by keys='2nd' (the date column - from parameterized tests), it triggers the deprecation warning internally during the groupby operation. Without it, those test cases fail in CI. So, added the filterwarnings.

Hmm so is that a problem with the groupby internals or the test data? This feels like something we shouldn't have to filter on this test

Yeah, you're right. The issue is that it's warning when groupby internally calls get_loc() on column names, not just user-facing .loc calls. I'll add a parameter to only warn on user-facing indexing, not internal operations like groupby. That way we don't need to filter warnings.

WillAyd · 2025-11-10T14:13:23Z

pandas/tests/indexes/datetimes/test_indexing.py

        with pytest.raises(TypeError, match=msg):
            dti.get_loc(key)

+    @pytest.mark.filterwarnings(


Does this test still exhibit the expected behavior if you change the test to use ISO strings?

It works as expected. Updated the test to use ISO format strings instead and removed the filterwarnings.

WillAyd · 2025-11-10T14:14:00Z

pandas/tests/indexes/period/test_indexing.py

        tm.assert_series_equal(ts[[Period("2012-01-02", freq="D")]], exp)

    @pytest.mark.arm_slow
+    @pytest.mark.filterwarnings(


You can change the test data here to use ISO strings, unless it explicitly tests non-ISO for a reason

Converting all the dates to ISO format in this test.

raghavendranath

@WillAyd Fixed all your comments. Ready for review whenever you get a chance.

WillAyd · 2025-11-12T22:38:26Z

pandas/core/indexes/datetimes.py

+        # - Followed by: hyphen (YYYY-), T (YYYY-T...), or end (YYYY)
+        # Examples that match: "2024", "2024-01", "2024-01-10", "2024-01-10T00:00:00"
+        # Examples that don't: "01/10/2024", "2024 01 10", "1/1/2024"
+        return re.match(r"^\d{4}(?:-|T|$)", date_str) is not None


This regular expression seems like it would catch way more than what is expected. Wouldn't this match something like 2025-ANYTHING-GOES?

Yeah, I checked and the loose regex actually works fine. Those invalid strings fail at the parsing step before reaching the regex check. But you have a point, so I'll tighten the regex to be more defensive. Also adding a test case for "2025-ANYTHING-GOES" to make sure it's handled right.

Yea we definitely want this to be strict. Ultimately its not relevant whether another part of the code base "catches" the issue, because refactors happen and invariants change. If the function is going to be called is_iso_format_string then it should only return True when the string is actually ISO

WillAyd · 2025-11-12T22:40:35Z

pandas/tests/groupby/methods/test_value_counts.py

 @pytest.mark.parametrize("bins", [None, [0, 5]], ids=repr)
 @pytest.mark.parametrize("isort", [True, False])
 @pytest.mark.parametrize("normalize, name", [(True, "proportion"), (False, "count")])
+@pytest.mark.filterwarnings(


Hmm so is that a problem with the groupby internals or the test data? This feels like something we shouldn't have to filter on this test

WillAyd · 2025-11-12T22:40:57Z

pandas/tests/groupby/test_groupby.py

    tm.assert_frame_equal(result, expected_output)


+@pytest.mark.filterwarnings(


This is another one that I don't think should have warnings

WillAyd · 2025-11-12T22:41:36Z

pandas/tests/indexes/datetimes/test_partial_slicing.py



 class TestSlicing:
+    pytestmark = pytest.mark.filterwarnings(


Does this apply to the entire class? Can we apply to the failing tests instead?

…d add test suppressions

raghavendranath changed the title ~~DEPR: Deprecate non-ISO date string formats in DatetimeIndex.loc #58302~~ DEPR: Deprecate non-ISO date string formats in DatetimeIndex.loc Nov 5, 2025

raghavendranath force-pushed the depr-datetimeindex-loc-slice-dayfirst branch 5 times, most recently from 415367c to 109e1c2 Compare November 7, 2025 03:02

raghavendranath mentioned this pull request Nov 7, 2025

BUG: .loc with DateTimeIndex allows day first string for stop in slice, but not start #58302

Open

3 tasks

natmokval added the Indexing Related to indexing on series/frames, not to indexes themselves label Nov 9, 2025

WillAyd requested changes Nov 10, 2025

View reviewed changes

raghavendranath commented Nov 11, 2025

View reviewed changes

raghavendranath force-pushed the depr-datetimeindex-loc-slice-dayfirst branch from b82bf18 to 936847d Compare November 11, 2025 05:36

raghavendranath requested a review from WillAyd November 11, 2025 05:43

WillAyd requested changes Nov 12, 2025

View reviewed changes

raghavendranath added 15 commits November 20, 2025 12:30

DEPR: Deprecate non-ISO date string formats in DatetimeIndex.loc

e090f54

added a new line back to docs

df128fc

moved the warnings after parsing

0153913

fix: only warn on non-ISO formats in .loc indexing paths

6667cce

removed pytestmark in test_partial_slicing

6838852

Fix: Ensure non-ISO deprecation warnings trigger in slice_indexer an…

1b48d87

…d add test suppressions

updated comments

13555ca

Fix: Use ISO format date strings in documentation example

edc8261

Fix: Add additional filter warnings to the failing tests

81f0cf5

Fix: Add filterwarnings to test_series_groupby_value_counts

306b2b1

fixing the doc upload warnings

e36c2e1

removed extra line in datetimes.py

a88db1b

Fix: updated timeseries.rst

adae1b2

fixed format errors

fd49ac4

fix lint errors

ab2d8bc

raghavendranath force-pushed the depr-datetimeindex-loc-slice-dayfirst branch from 936847d to ab2d8bc Compare November 20, 2025 07:01

		return result


		def _is_iso_format_string(date_str: str) -> bool:

		tm.assert_frame_equal(result, expected_output)


		@pytest.mark.filterwarnings(

Uh oh!

DEPR: Deprecate non-ISO date string formats in DatetimeIndex.loc #62991

Are you sure you want to change the base?

DEPR: Deprecate non-ISO date string formats in DatetimeIndex.loc #62991

Conversation

raghavendranath commented Nov 5, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

raghavendranath commented Nov 9, 2025

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

raghavendranath Nov 11, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

raghavendranath Nov 11, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

raghavendranath left a comment • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

raghavendranath commented Nov 5, 2025 •

edited

Loading

raghavendranath Nov 11, 2025 •

edited

Loading

raghavendranath Nov 11, 2025 •

edited

Loading

raghavendranath left a comment •

edited

Loading