Allow development to accept an age in months relative to origin - #1229
Allow development to accept an age in months relative to origin#1229Abhayindia wants to merge 1 commit into
Conversation
Pyright Type CompletenessView the full Project (full
Other symbols referenced but not exported by
Symbols without documentation:
Patch (exported symbols added or changed by this PR): 100.0% fully typed (3 / 3); 1 no longer exported
Patch symbol details
|
|
just unblocked tests. expecting ruff and codecov fails. |
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #1229 +/- ##
==========================================
- Coverage 91.31% 91.23% -0.09%
==========================================
Files 91 92 +1
Lines 5434 5451 +17
Branches 700 704 +4
==========================================
+ Hits 4962 4973 +11
- Misses 336 340 +4
- Partials 136 138 +2
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
Closes #1094 (the enhancement route agreed with @henrydingliu in that thread).
_to_datetimetries%Y%m,%Y,%Y-%m-%dand then falls through to a barepd.to_datetime, which for a numeric column silently reads the values as nanoseconds since epoch. That collapsed age-lag columns like[12, 24, 36]to 1970-01-01, and the old guard just checked whether the result landed in 1970 - so a triangle whose development really is the year 1970 got the same error.This replaces that with a check at the point of parsing: if none of the explicit formats matched and the column is numeric, it's an age in months.
_init_developmentthen resolves each value to the valuation date that many months after the start of that row's origin period. Ages are measured from the origin period start (using the constructor's ownorigin_grain, so mid-period origin dates and fiscal-year anchors line up), not the literal recorded origin date. Bare years still match%Yand are untouched. Non-numeric unparseable input still raises, with the same message as before. Semiannual grains only support the calendar Jan/Jul anchor; a non-calendar one raises a clear error rather than guessing.Verified:
Full suite was 1091 passed / 8 skipped when I posted the branch on the issue.