[AdrianAtZyte]

No description provided.

[codspeed]

Merging this PR will not alter performance

✅ 10 untouched benchmarks

---

_{Comparing AdrianAtZyte:fix-1.5.0-regressions (39bbd7c) with master (2d93cdc)}

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 99.20%. Comparing base (b1a87f9) to head (39bbd7c).
⚠️ Report is 1 commits behind head on master.

Additional details and impacted files

@@           Coverage Diff           @@
##           master    #1554   +/-   ##
=======================================
  Coverage   99.19%   99.20%           
=======================================
  Files         239      239           
  Lines        4098     4137   +39     
=======================================
+ Hits         4065     4104   +39     
  Misses         33       33           

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[serhii73]

I reviewed this and ran it against v1.4.3 and current master. I am not approving yet, because one issue should be fixed before 1.5.0.

Blocking: new quadratic time in sanitize_date(). _decimal_comma_to_point() calls re.search(r"\d{4}", match.string, endpos=match.start()) for every hh:mm:ss,dddd match, so each match rescans everything before it. sanitize_date() runs on every parse() input.

sanitize_date("a" * 200000 + " 2021 " + "10:00:00,1234 " * 8000)

This takes 3.6 s on this branch, against 0.016 s on master and 0.013 s on v1.4.3, and the time doubles with the number of matches. It is the same class of problem as the pending security advisories, and 1.4.3 does not have it.

Finding the first run of four digits once avoids it. With the change below the case above takes 0.02 s, the results are unchanged and the full suite passes (25083):

Patch

+RE_FOUR_DIGITS = re.compile(r"\d{4}")
...
-    date_string = RE_SANITIZE_DECIMAL_COMMA.sub(_decimal_comma_to_point, date_string)
+    first_four_digits = RE_FOUR_DIGITS.search(date_string)
+    year_end = first_four_digits.end() if first_four_digits else None
+    date_string = RE_SANITIZE_DECIMAL_COMMA.sub(
+        lambda match: _decimal_comma_to_point(match, year_end), date_string
+    )
...
-def _decimal_comma_to_point(match: re.Match[str]) -> str:
+def _decimal_comma_to_point(match: re.Match[str], year_end: int | None) -> str:
...
-        and not re.search(r"\d{4}", match.string, endpos=match.start())
+        and not (year_end is not None and year_end <= match.start())

Non-blocking differences from current master (not from v1.4.3), in case you want to look:

• parse("Posted on Jan 5 MMX", settings={"IGNORE_SURROUNDING_TEXT": True}) now returns 2026-01-05 instead of 2010-01-05, with no error. The retry never calls _parse_with_short_roman_year.
• With _MAX_EXPRESSION_LENGTH = 50, search_dates("and " * 11 + "in 2 days 2020-09-01", languages=["en"]) loses the 2020-09-01 result. 10 repetitions still find it.
• Thu, 30 May 2024 10:13:10 -0500 CDT (CDT) and strings with three equivalent timezone tokens parse on master but return None now, because only one extra token is popped. They also returned None in 1.4.3.