Skip to content

CI/BLD: don't use strict xfail for '%m.%Y' format in test_hypothesis_delimited_date #62124

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged

Conversation

jorisvandenbossche
Copy link
Member

Closes #62093

The last days, some linux wheel builds have been failing while testing with:

   ________________ test_hypothesis_delimited_date[%m %Y-False-.] _________________
  [XPASS(strict)] parse_datetime_string cannot reliably tell whether e.g. %m.%Y is a float or a date

I am not directly sure what is going on (it also only happens on wheel builds, and it is a hypothesis tests, so I am not even sure when this happens (i.e. with which input data). Do we print somewhere some hash so we can reproduce hypothesis failures?).
And it is also not happening consistently on the same builds (in one nightly build, it failed for cp312-musllinux_aarch64, but then in another for cp313, in another for manylinux, etc).

So for now just making this a non-strict xfail to get the nightly wheels working

@jorisvandenbossche jorisvandenbossche added the Build Library building on various platforms label Aug 15, 2025
@jbrockmendel
Copy link
Member

i think ive seen this locally too a couple times.

@mroeschke didn't you have a recent PR that tinkered with hypothesis settings?

Copy link
Member

@mroeschke mroeschke left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, I tweaked hypothesis to run less max_examples, but I've seen this flakily fail over the years so OK to set strict=False here.

(We should probably increase the hypothesis verbosity since I've had trouble reproducing this locally in the past)

@mroeschke mroeschke merged commit 50a8079 into pandas-dev:main Aug 15, 2025
91 of 115 checks passed
@mroeschke
Copy link
Member

Thanks @jorisvandenbossche

meeseeksmachine pushed a commit to meeseeksmachine/pandas that referenced this pull request Aug 15, 2025
…%Y' format in test_hypothesis_delimited_date
@jorisvandenbossche jorisvandenbossche deleted the ci-nightly-wheels-date-format branch August 15, 2025 18:29
mroeschke pushed a commit that referenced this pull request Aug 15, 2025
…r '%m.%Y' format in test_hypothesis_delimited_date) (#62128)

Co-authored-by: Joris Van den Bossche <[email protected]>
@jbrockmendel
Copy link
Member

do we have any other ideas to troubleshoot before the cement sets on this? strict=False makes a test pretty useless

@mroeschke
Copy link
Member

do we have any other ideas to troubleshoot before the cement sets on this?

Probably just run this test without the xfail marker (in CI) and increased hypothesis verbosity to actually see what input data is failing. I've not been able to reproduce this locally in the past

@jorisvandenbossche
Copy link
Member Author

Trying to understand what the test was doing, I just hardcoded it with a random datetime, and with the first one I tried the test is already failing for me .. (I am better than hypothesis ;))

--- a/pandas/tests/tslibs/test_parsing.py
+++ b/pandas/tests/tslibs/test_parsing.py
@@ -398,12 +398,12 @@ def _helper_hypothesis_delimited_date(call, date_string, **kwargs):
 def test_hypothesis_delimited_date(
     request, date_format, dayfirst, delimiter, test_datetime
 ):
+    test_datetime = datetime(2000, 2, 1, 9)
     if date_format == "%m %Y" and delimiter == ".":
         request.applymarker(
             pytest.mark.xfail(
                 reason="parse_datetime_string cannot reliably tell whether "
                 "e.g. %m.%Y is a float or a date",
-                strict=False,
             )
         )
     date_string = test_datetime.strftime(date_format.replace(" ", delimiter))

and then running this gives two XPASS(strict) failures.

So in practice, I think this test only fails if the month is larger than 10, because for formatted date strings like '02.2000', the parsing function works "fine" (it gives complete garbage as far as I can see, but it gives the same as dateutil, and that is what is being tested):

>>> from pandas._libs.tslibs import parsing
>>> parsing.py_parse_datetime_string("02.2000")  # was formatted as %m.%Y, so should be 2000, 2, 1
datetime.datetime(1, 1, 2, 0, 0)
>>> parsing.py_parse_datetime_string("10.2000")
...
ValueError: Given date string "10.2000" not likely a datetime

So in summary, we can probably tune that xfail check to allow it be strict, but I am also not entirely sure what is actually being tested for this case of format string ...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Build Library building on various platforms
Projects
None yet
Development

Successfully merging this pull request may close these issues.

BUILD: Nightly wheel building failed for some platforms
3 participants