Support decimal values in dehumanize

[dchaudhari7177]

Fixes #1237.

Problem

>>> arrow.get("2025-12-10T09:00:00").dehumanize("2 days 3.5 hours ago")
<Arrow [2025-12-08T04:00:00+00:00]>   # 2 days 5 hours

The number pattern is \d+, so for 3.5 hours the search lands on the digits after the separator and the 3 is dropped. Expected <Arrow [2025-12-08T05:30:00+00:00]>.

Fix

The pattern becomes \d+(?:[.,]\d+)?, shared as _NUMBER_PATTERN between the two places that needed it (the per-timeframe search string and the number extraction). A matched value keeps parsing as int when it has no fraction, so nothing changes for the strings humanize() produces — only the new decimal case yields a float.

relativedelta accepts floats for seconds through weeks, so shift() needed no change.

On the separator

Both . and , are accepted, as the issue suggests. The locale objects carry no decimal-separator information, and dehumanize input is written by hand rather than produced by humanize(), so there is nothing to key the choice off. The separator only counts when digits follow it, which is what keeps it from firing on a locale's own punctuation.

The trade-off is that digit grouping ("1,500 hours") is read as 1.5. That input is already wrong today — \d+ matches just 1 — so this is not a regression, but it is not a case I tried to support; I noted it in a comment next to the pattern. Happy to restrict to . only if you would rather not accept the ambiguity.

Fractional months and years

relativedelta rejects these outright ("Non-integer years and months are ambiguous and not currently supported"), which surfaces as a ValueError from dehumanize. That seemed better than silently truncating; there is a test pinning it.

Tests

• test_fractional_value — hours, minutes and days, both directions.
• test_fractional_value_comma_separator — 1,5 matches 1.5.
• test_fractional_value_with_multiple_units — the exact case from the issue, plus its future form.
• test_fractional_months_and_years_are_rejected.

Full suite passes (1903 passed, 1 skipped).

🤖 Generated with Claude Code

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 100.00%. Comparing base (2224255) to head (b30820a).

Additional details and impacted files

@@            Coverage Diff            @@
##            master     #1334   +/-   ##
=========================================
  Coverage   100.00%   100.00%           
=========================================
  Files           10        10           
  Lines         2315      2317    +2     
  Branches       358       358           
=========================================
+ Hits          2315      2317    +2     

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

[Copilot]

Pull request overview

This PR fixes Arrow.dehumanize() so it correctly parses fractional (decimal) quantities like "3.5 hours" (and "3,5 hours") instead of incorrectly matching only the digits after the separator, addressing issue #1237.

Changes:

• Introduces a shared _NUMBER_PATTERN that matches integers or decimals (\d+(?:[.,]\d+)?) and uses it both for timeframe matching and number extraction.
• Parses matched numeric values as int when integral and float when fractional (normalizing , to .), relying on relativedelta float support for seconds–weeks.
• Adds tests covering fractional units (including multiple units and comma separator) and pins the ValueError behavior for fractional months/years.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated no comments.

File	Description
arrow/arrow.py	Updates dehumanize() regex matching and numeric parsing to support decimal values via a shared _NUMBER_PATTERN.
tests/test_arrow.py	Adds targeted tests for decimal parsing, comma separators, multi-unit strings, and fractional months/years error behavior.

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[dchaudhari7177]

The red windows-latest (pypy-3.11) check here is infrastructure, not this change. The job failed before running any test:

ERROR: Could not install packages due to an OSError: ('Connection broken: IncompleteRead(37256 bytes read, 1054 more expected)')
ERROR: Failed to build 'pyyaml' when installing build dependencies for pyyaml

A truncated PyPI download while building pyyaml from source on the pypy runner. Every other job in the matrix is green, and #1333 failed identically on the same runner in a separate run. A re-run should clear it — I do not have permission to trigger one here.

Re-ran the suite locally on this branch to be sure: 1903 passed, 1 skipped.

[Mukller]

Verified locally against upstream master and this branch (Python 3.13, editable install):

Master's decimal handling is silently wrong, this fixes it precisely:

input	master	branch
"2 hours ago"	−2h ✓	−2h ✓
"1.5 hours ago"	−5h (!)	−1.5h ✓
"0.5 days ago"	−5 days (!)	−0.5d ✓
"1.5 days ago"	—	−36h ✓

Master appears to split on the decimal point and treat fragments independently, so "0.5" becomes ~5 units and "1.5" becomes 1+5-ish depending on unit — a silent multi-hour/multi-day error for any user passing fractional strings. The _NUMBER_PATTERN = r"\d+(?:[.,]\d+)?" plus float-typed time_object_info fix handles both . and , separators correctly (verified 1.5 above; comma path covered by the added tests).

Scope note: I probed the future direction too — "2 hours later" raises ValueError identically on master and this branch, i.e. that's a pre-existing limitation of dehumanize's grammar ("in N units" works on both), not something this PR regresses or needs to solve. Might make a good follow-up issue.

pytest tests/test_arrow.py -k dehumanize passes on the branch (the single collection error in my run was an unrelated fixture dependency).

Approving.