Skip to content

fix: avoid counting partial intervals as full months - #1043

Open
sricharanreddycheruku wants to merge 1 commit into
python-pendulum:masterfrom
sricharanreddycheruku:new/fix-partial-month-intervals
Open

sricharanreddycheruku wants to merge 1 commit into
python-pendulum:masterfrom
sricharanreddycheruku:new/fix-partial-month-intervals

Conversation

@sricharanreddycheruku

Copy link
Copy Markdown

Fixes #790.

Intervals such as January 3 to February1 in a leap year incorrectly report a full month because the day difference happens to match the difference between the month lengths. Restrict that special case to month-end endpoints in both the Python and Rust helpers.

Tests cover leap and nonleap years, reversed intervals, the reported Toronto in_months() behavior, time borrowing, and the existing January 31-to-February28/29 clipping rule. Two existing month-end tests now freeze time in the same Toronto timezone used by today(), preserving their expected results while exercising their intended dates.

Pull Request Check List

  • Added tests for changed code.
  • Updated documentation for changed code. No new API or documented behavior.

Validation on Python 3.12.3: full Rust-extension and pure-Python suites each passed 1878 tests with 3 skips. The new regression tests fail 5 cases on unchanged master in each backend and pass after the fix. Mypy passed all 228 source files; Ruff 0.14.11 check and formatting passed; cargo fmt and cargo clippy --tests -- -D warnings passed.

All six prek hooks passed, including Rust lint.

This branch has not been deployed

No deployments
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

in_months() returns wrong values in some cases in January to February

1 participant