fix(bulma-ui): read picker bounds and months in years 0 to 99 as written

[allxsmith]

The picker's date helpers built dates with the multi-argument Date constructor, which reads years 0 to 99 as 1900 to 1999. #866 added a setter-based makeDate for the month and year grids; this moves the sites below onto it.

• startOfDay and endOfDay, which normalize min and max, so a bound in those years was misread.
• startOfMonth and endOfMonth, the same bug in the same file: startOfMonth lays out the day grid, so a year-19 month drew 1919 and disabled every day, and month keyboard navigation compares against it.
• The month-length clamp in addMonths, which read February of year 0 as February 1900, not a leap year, and its twin daysInMonth in segmented typing.
• The native inputs' read-back, fromIsoValue and fromIsoDateTime, so a native date pick in year 19 committed 1919. They also take a year of four or more digits now, as HTML allows, so a pick past 9999 commits that date instead of null.
• toIsoDateTime, which didn't pad the year, so a year below 1000 gave datetime-local an invalid value, min, and max. It pads to four digits now, as toIsoValue already did.
• parseDate, the pickers' default parse. The field shows year 19 as 0019, and the old round-trip check turned that into null, so the field couldn't read its own text back. This is the one change a user sees in free-text entry: a typed year below 100 now parses to that year, and dates like 30 February are still rejected.

New tests cover each of these. Year 0 and earlier still don't fit the native inputs, which is a product decision tracked in #902.

pnpm all passes locally.

[coderabbitai]

Warning

Review limit reached

You've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository.

Next included review available in 41 minutes.

Check out review usage here.

View limit details

Limit details: You’ve used the included review currently available.

Learn how review limits work.

Review configuration:

⚙️ Run configuration

• Configuration used: Repository: allxsmith/bestax/.coderabbit.yaml
• Review profile: CHILL
• Plan: Advanced
• Run ID: 29530fa9-1a8e-49f2-b5f0-03a10a08c385

📥 Commits

Reviewing files that changed from the base of the PR and between 99426b4 and e4e0466.

📒 Files selected for processing (11)

• bulma-ui/src/form/DateInputBase.tsx
• bulma-ui/src/form/DateTimeInputBase.tsx
• bulma-ui/src/form/__tests__/Calendar.test.tsx
• bulma-ui/src/form/__tests__/DateInput.test.tsx
• bulma-ui/src/form/__tests__/DateTimeInput.test.tsx
• bulma-ui/src/form/__tests__/dateUtils.test.ts
• bulma-ui/src/form/__tests__/formatters.test.ts
• bulma-ui/src/form/__tests__/segmentMap.test.ts
• bulma-ui/src/form/_pickerInternals/dateUtils.ts
• bulma-ui/src/form/_pickerInternals/formatters.ts
• bulma-ui/src/form/_pickerInternals/segmentMap.ts

• Autopilot · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[github-actions]

Preview Deployment

Preview URL: https://454e0fd7.bestax.pages.dev

[claude]

Deep review — 2 blocking · 3 advisory

#	Severity	Area	Finding	Location
1	🟠 Major	Correctness	Native day picker's ISO read-back still remaps years 0–99 (new Date(19, …) → 1919), while the 'month' branch beside it already uses makeDate; min/max reach the same input through the padded toIsoValue, so the bound fix is undone one layer up	bulma-ui/src/form/DateInputBase.tsx:68
2	🟡 Minor	Correctness	The month-length clamp this PR fixed in addMonths has a byte-for-byte twin in segmented keyboard entry, feeding five clamps; 29 February year 0 clamps to the 28th	bulma-ui/src/form/_pickerInternals/segmentMap.ts:156
3	🔵 Advisory	Correctness	parseDate is still constructor-based. The PR body's reasoning is right — the round-trip check nulls any year below 100 rather than misreading it — but the consequence is that a year-0–99 bound or value can only ever be set programmatically, never typed, so the day/month grids this PR fixes are reachable with such a year only from props	bulma-ui/src/form/_pickerInternals/formatters.ts:144
4	🔵 Advisory	Robustness	toIsoDateTime does not pad the year (DateInputBase.toIsoValue does), so DateTimeInput's native round trip for a year below 1000 fails the \d{4} regex on read-back instead of misreading it. Pre-existing and outside this PR's stated scope — on the record because it is why finding 1's twin at DateTimeInputBase.tsx:62 is harder to reach	bulma-ui/src/form/DateTimeInputBase.tsx:41
5	🔵 Advisory	API	The new free-floating comment scopes the change to min/max, but startOfMonth also lays out the day grid — which the commit message says and this comment does not. Imprecise rather than false; deleting the "a min or max" clause so it reads "…so a date in years 0–99 keeps its year" would cover both	bulma-ui/src/form/_pickerInternals/dateUtils.ts:35

Overall: The core change is sound and well-targeted — swapping the four boundary helpers and the addMonths clamp onto the setter-based makeDate is semantically identical for years ≥ 100 (both paths go through MakeDay/MakeTime), endOfMonth's makeDate(y, m + 1, 0) handles the December wrap correctly via setFullYear's month-overflow rule, and Invalid Date / negative / out-of-range years behave exactly as before. Every new test is a genuine regression test: each one's assertion is falsified by the pre-fix expression (startOfDay → 1919-02-20, the day grid built from 1919-06-01, isPeriodUnselectable comparing a year-19 June against a 1919 min, and the year-0 February clamp returning 28). The riskiest part is not what the diff changed but what it did not: the same constructor remains in two adjacent executable paths that the fixed helpers hand off to, and finding 1 is the only place left where an early year produces a silently wrong value rather than a wrong-looking grid. Look at that one first.

Residual risk:

• Refuted — the four rewritten helpers for ordinary years. makeDate seeds from new Date(2000, 0, 1), so TimeWithinDay is 0 and setFullYear(y, m, d) reduces to the same MakeDay/local-offset computation the constructor performs; endOfDay/endOfMonth's added setHours(23, 59, 59, 999) is the same MakeTime the old literal arguments produced. All 38 src/form suites (1636 tests) pass on the branch.
• Refuted — endOfMonth on December. makeDate(y, 12, 0) relies on MakeDay's ym = y + floor(m / 12): month 12 resolves to January of y + 1, day 0 steps back to 31 December of y. The pre-existing endOfMonth tests (including the non-leap February case) still pass.
• Refuted — parseDate. formatters.ts:145-152 re-reads getFullYear()/getMonth()/getDate() off the constructed date and returns null on any mismatch, so a parsed year below 100 is rejected, never misread. The PR body's claim checks out.
• Refuted — no other remaining sites in picker source. A grep for multi-argument new Date( across non-test bulma-ui/src leaves only the three findings above plus formatters.ts:317,334, which build fixed 2021 reference dates to harvest weekday/month names and never see a caller's year.
• Open (posted as finding 1) — DateInputBase.fromIsoValue, day granularity: the native <input type="date"> round trip. This is the one that matters, because toIsoValue deliberately pads the year to four digits, so our own serialization does feed it 000Y-MM-DD.
• Open (posted as finding 2) — segmentMap.daysInMonth, the twin of the clamp the diff fixed. Narrow: among years 0–99 only year 0's February length differs from its 19xx remap, so the visible defect is confined to 29 February year 0.
• Open (bullet, not posted) — DateTimeInputBase.fromIsoDateTime at line 62 carries finding 1's exact expression, but its serializer does not zero-pad the year, so reaching it needs a native datetime-local to hand back a 000Y-… string on its own rather than echoing ours. Same one-word fix if finding 1 is taken.

Note on anchoring: both blocking findings live in files this PR does not touch, so GitHub rejects a line comment there. They are anchored on the nearest diff line in dateUtils.ts (the new boundary comment and the fixed addMonths clamp) and each names its real file and line in the body.

🏄 Clean little set-and-forget, dude — the gnarly 1900-year rip in the bounds is patched, and every new test actually wipes out on the old code, which is how you know they're real. Just two spots downstream still paddling the old board; grab fromIsoValue before you call it glassy.

[github-actions]

Preview Deployment

Preview URL: https://569946de.bestax.pages.dev

[claude]

Deep review (verify) — 2 resolved · 0 open

#	Severity	Area	Finding	Location
1	🟠 Major	Correctness	Native day/datetime read-back remapped years 0–99 — fixed, resolved	bulma-ui/src/form/DateInputBase.tsx:68
2	🟡 Minor	Correctness	The daysInMonth twin in segmentMap was left on the multi-arg constructor — fixed, resolved	bulma-ui/src/form/_pickerInternals/segmentMap.ts:159

What I checked

• #1 — the day branch of fromIsoValue (DateInputBase.tsx:68) now calls makeDate, matching the month branch beside it. DateTimeInputBase.fromIsoDateTime (DateTimeInputBase.tsx:61-62) was converted too, splitting the old 7-argument constructor into makeDate(...) plus setHours(h, m, s, 0) — behaviourally equivalent, and the explicit 0 keeps milliseconds pinned, which the new assertion checks alongside the dropped-fractional-seconds path. New tests commit 0019-03-04 and 0019-03-04T14:30:55 back as year 19, and the first also asserts native.min === "0019-01-01", so the padded toIsoValue → read-back round trip is closed end to end.
• #2 — segmentMap.ts:159-160 builds on the now-imported makeDate (line 15), so all five consumers — the month increment (189), the day-increment wrap modulus (194), and the year / month / day digit writes (260, 272, 283) — see February of year 0 as 29 days. The three new assertions pin the increment (28 Feb year 0 → the 29th), the day write (29 holds), and a year-0 digit write off 29 Feb 2024.

Tests run: the four date suites (DateInput, DateTimeInput, segmentMap, dateUtils) — 314 passed; -t "year below 100" — 13 passed. I could not re-run the suites against the pre-fix source (reverting the three files was not permitted in this sandbox), so the "fails on previous head" claim rests on the ECMAScript semantics the findings cited (new Date(19, …) → 1919; 1900 is not a leap year while year 0 is) plus the year-0 and year-19 assertions in the tests themselves, which cannot pass through the old constructor.

Overall: this pass settled the two open threads and reviewed no commits. Both findings are genuinely fixed at the sites named, with tests that pin the exact boundaries, and the only non-mechanical edit — the fromIsoDateTime split — preserves the time-of-day and millisecond behaviour the surrounding tests already cover. Nothing is left open; a human reviewing this should focus on whether the deliberate parseDate exemption (a year below 100 becomes null), called out in the PR body, is the behaviour they want for typed text input.

Residual risk: verify-pass scope — the ways the early-year class could still occur were enumerated in the residual-risk section of the prior review and are not re-opened here. Of what that pass flagged, both executable gaps are now closed; the one remaining acknowledged path is the round-trip check in parseDate, which fails closed to null rather than misreading, and is documented as intentional in the PR body.

🏄 Two gnarly little 1900-year riptides got patched clean, brah — every early-year date now rides its own wave from the native input all the way through segment typing. Threads closed, tests green, this one is good to paddle out.

[github-actions]

📸 Story screenshots at handoff — e4e0466

No Storybook stories map to this PR's changed files — nothing to screenshot. (workflow run)

[github-actions]

Preview Deployment

Preview URL: https://c30b9850.bestax.pages.dev

[allxsmith]

Every finding from the reviews, fixed or answered:

1. The native day picker's read-back: fixed in 306589c, verified by the last pass.
2. segmentMap's month-length clamp: fixed in 306589c, verified by the last pass.
3. parseDate still used the constructor: fixed in 5bfaf3c. The field pads year 19 to 0019, so it couldn't read its own text back; it now builds on makeDate and still rejects dates like 30 February.
4. toIsoDateTime didn't pad the year: fixed in 5bfaf3c. It pads to four digits, so a year below 1000 gives datetime-local a valid value, min and max, and the inline form value shares the helper.
5. The dateUtils comment scoped the change to bounds: fixed in 306589c.

Both new tests fail on 306589c.

[allxsmith]

deep-review: fresh

The advisories from the last review are fixed or answered in the comment above; this reviews 5bfaf3c.

[claude]

Deep review — 0 blocking · 3 advisory

#	Severity	Area	Finding	Location
1	🔵 Advisory	Robustness	Year 0 still cannot reach the native inputs: both ISO builders now emit 0000-01-01…, and the HTML valid-date grammar requires year > 0, so a year-0 value/min/max is silently dropped by <input type="date"> / datetime-local. Not a regression (the unpadded 0-01-01… was invalid too), and year 0 is only ever transient in segmented typing, which does not render the native input — but the helper-level tests in this PR pin year 0, so the asymmetry is worth recording	bulma-ui/src/form/DateTimeInputBase.tsx:43
2	🔵 Advisory	Robustness	Years above 9999 are the mirror hole: padStart(4, "0") does not truncate, so toIsoDateTime/toIsoValue emit a 5-digit year that the anchored ^(\d{4})- read-back regexes cannot match, and a native pick in such a year commits null. Pre-existing on both sides of the round trip and untouched here	bulma-ui/src/form/DateTimeInputBase.tsx:54
3	🔵 Advisory	Robustness	Negative (BCE) years: String(-5).padStart(4, "0") → 00-5, an invalid native value, so the bound is ignored rather than enforced — again the same outcome as before the padding. Adjacent to this: with an early focused year and no min, the default year window in Calendar is windowYear - 100, so a year-19 picker lists years down to -81, and makeDate builds them happily. Untouched file, and the no-min/max case only	bulma-ui/src/form/_pickerInternals/Calendar.tsx:429

Overall: Sound, and now complete for the failure class it names. Every date-bearing construction in bulma-ui/src/form is off the multi-argument Date constructor: a grep of the tree leaves only parseTime, TimeInputBase.fromIsoTime (both anchored on the current year, so the 0–99 remap is unreachable), the fixed 2021 anchors in getDayNames/getMonthNames, and the new Date(2000, 0, 1) base inside makeDate. The two non-mechanical edits are the riskiest part and both check out: splitting parseDate into makeDate(...) + setHours(h, m, s, 0) is behaviourally identical to the old 7-argument call for every year ≥ 100 — including the day-overflow (2024-02-30 → null), spring-forward (2024-03-10 02:30 → 03:30) and whole-day-skip (Pacific/Apia 2011-12-30 → null) cases, because the round-trip guard is unchanged and both paths resolve the same local time — and endOfMonth with makeDate(y, m + 1, 0) wraps December correctly through the month-overflow rule of setFullYear (setFullYear(19, 12, 0) → 31 Dec year 19). A human should look first at advisory 1: the helper tests here treat year 0 as in scope, while the native input path can still only represent years 1–9999.

Residual risk:

• Other picker paths that lay out early years — refuted. buildMonthGrid goes through startOfMonth/addDays (setters), the month grid through makeDate(focusedYear, m), the year grid through makeDate(year) and setFullYear, and the header step through addMonths/addYears, whose clamp this PR moved onto makeDate. The prevDisabled/nextDisabled comparisons in Calendar are made against startOfDay(min)/startOfDay(max), so they are fixed by the same diff.
• Segmented keyboard entry through an early year — refuted. The year digit write uses next.setFullYear(yr), and the month/day/increment clamps all route through the now-fixed daysInMonth; the three new segmentMap assertions pin February of year 0 at 29 days for the increment, the day write and a year-0 digit write.
• A displayed early-year value that cannot be typed back — refuted. YYYY renders year 19 as 0019 and parseDate("0019-03-04 14:30", …) now returns year 19, while parseDate("0019-02-29") still returns null (19 is not a leap year), so the round-trip guard is intact. YY is unaffected — it maps into the 2000s before any date is built.
• Native round trip for years 1–999 — refuted end to end: native.min === "0019-01-01" plus a 0019-03-04 change event committing year 19 for DateInput, and "0019-03-04T14:30" with native.min === "0019-01-01T09:00" for DateTimeInput.
• Open: years 0, above 9999, and negative years on the native path (advisories 1–3). All three are limits of the HTML value grammar or of the fixed-width read-back regexes rather than year remapping, and none is a regression from this diff.
• Verification note: the three source files could not be reverted in this sandbox, so the claim that the new tests fail on main rests on the ECMAScript semantics those tests encode (new Date(19, …) → 1919; year 0 is a leap year while 1900 is not; an unpadded 19-03-04T14:30 is not a valid datetime-local value) plus assertions that cannot hold through the old constructor. Run here on the PR head: the six date suites — 462 passed; the whole src/form tree with coverage — 1642 passed, with dateUtils.ts and segmentMap.ts at 100% statements and branches and src/form overall at 99.73% / 99.35%; typecheck:tests clean; prettier clean on all eleven changed files. No public API moved — parseDate is internal — so no docs, story or skills/ update is owed.

🏄 Three commits of patient paddling and the early-year swell is fully ridden — every new Date(19, …) trap in the picker is off the reef, the new tests actually bite, and the only water left is the year-0 and five-digit shorebreak that HTML itself will not let you surf. Clean ride, good to go.

[allxsmith]

On the latest review's findings, all answered with no code change:

1. Year 0 can't reach the native inputs: refuted. HTML's valid date grammar requires a year above 0, so <input type="date"> and datetime-local can't represent year 0 however it's written; 0-01-01 was dropped before this PR and 0000-01-01 is dropped now. Year 0 only appears in passing while segmented typing builds a four-digit year, and segmented entry doesn't render the native input. This PR claims years 1 to 99.
2. Years above 9999 don't round-trip: refuted. No one picks a date past 9999, and the hole is on both sides of the round trip before this PR: the read-back patterns and parseDate's YYYY token take exactly four digits. Widening them changes text parsing this PR doesn't touch, for an input no user hits.
3. Negative years, and the calendar's year window: refuted. Native date inputs can't represent negative years, so such a bound was ignored before this PR and still is. The year window reaching below 0 needs an early focused year with no min, sits in a file this PR doesn't touch, and builds valid dates; neither is the 1900-to-1999 misreading this PR fixes.

[allxsmith]

deep-review: fresh

Main is merged in, so this review posts every finding, advisory included, as its own thread. It reviews ddaa7e6.

[github-actions]

Preview Deployment

Preview URL: https://19ce7e49.bestax.pages.dev

[claude]

Deep review — 1 blocking · 2 advisory

#	Severity	Area	Finding	Location
1	🟡 Minor	Correctness	PR body describes only the first of three commits, and its parseDate paragraph is now the opposite of the code: a year below 100 typed into the field parses rather than becoming null	bulma-ui/src/form/DateInputBase.tsx:68 (PR body — no line of its own)
2	🔵 Advisory	Robustness	Year 0 cannot reach either native input: 0000-… fails HTML's "year > 0" rule, while the helpers this PR tests pin year 0	bulma-ui/src/form/DateTimeInputBase.tsx:43
3	🔵 Advisory	Robustness	The mirror hole — a 5-digit year serializes fine but the \d{4} read-back rejects it (native pick commits null); a negative year emits 00-5 and the bound is ignored	bulma-ui/src/form/DateTimeInputBase.tsx:62

Overall: the change is sound and, as of the third commit, complete for the failure class it names. Every date-bearing construction in bulma-ui/src/form is now off the multi-argument Date constructor — a grep of non-test source leaves only parseTime / TimeInputBase.fromIsoTime (anchored on the current year, so the 0–99 remap is unreachable), the fixed 2021 anchors in getDayNames/getMonthNames, and makeDate's own new Date(2000, 0, 1) seed. The two non-mechanical edits both check out: splitting parseDate and fromIsoDateTime into makeDate(…) + setHours(h, m, s, 0) is behaviourally identical to the old 7-argument calls for every year ≥ 100, because makeDate seeds at local midnight so TimeWithinDay is 0 and setFullYear reduces to the same MakeDay, and the explicit trailing 0 keeps milliseconds pinned; endOfMonth's makeDate(y, m + 1, 0) wraps December through setFullYear's month-overflow rule. The riskiest thing left is not in the code — it is that the PR body now tells a reviewer the one public behaviour change (free-text entry of 0019-03-04 committing year 19 instead of null) did not happen. Look at finding 1 first and decide that change on purpose.

Empirically verified here on ddaa7e68: all 38 src/form suites, 1678 tests passed; with coverage, dateUtils.ts and segmentMap.ts at 100% statements/branches/functions/lines, DateTimeInputBase.tsx 100% statements, formatters.ts 99.4%, DateInputBase.tsx 100% lines — no coverage gap in any of the new code. No public export moved (parseDate, makeDate and daysInMonth are all internal; src/index.ts is untouched), so no story, API page or skills/ update is owed.

Residual risk:

• Native day and datetime round trip for years 1–999 — refuted end to end, not just by reading. DateInput: native.min === "0019-01-01" and a 0019-03-04 change event commits year 19. DateTimeInput: native.value === "0019-03-04T14:30", native.min === "0019-01-01T09:00", and 0019-03-04T14:30:55 commits [19, 2, 4, 14, 30, 55, 0].
• year granularity on the native path — refuted as unreachable, which is why fromIsoValue's missing year branch is not a finding. DateInputBase.tsx:323-325 gates hasNativeInput on isDayGranularity || (granularity === 'month' && …), so a year picker never renders a native control however mobileNative is set, and the existing test at DateInput.test.tsx:1667 asserts exactly that.
• Grid layout and keyboard navigation in an early year — refuted. buildMonthGrid goes through the now-fixed startOfMonth + addDays, the month grid through makeDate(focusedYear, m), the year grid through makeDate(year) / setFullYear, the header step through addMonths/addYears (whose clamp this PR moved onto makeDate), and prevDisabled/nextDisabled compare against startOfDay(min) / startOfDay(max). The new Calendar tests pin a year-19 day grid (10…20 enabled) and a year-19 month grid.
• Segmented keyboard entry passing through an early year — refuted. The year write is setFullYear, and the month/day/increment clamps all route through the fixed daysInMonth; three new assertions pin February of year 0 at 29 days for the increment, the day write and a year-0 digit write.
• DST-sensitive paths through the new makeDate + setHours split — refuted by the ECMAScript UTC(t) disambiguation rule: for a skipped local time the pre-transition offset is used, which moves the result forward, so makeDate can never land on the previous local day and setHours can never write the time onto the wrong date. The existing spring-forward, fall-back and skipped-day cases in formatters.test.ts and dateUtils.test.ts still pass.
• Open, not posted as a finding: makeDate seeds from new Date(2000, 0, 1) and never calls setHours(0, 0, 0, 0), so it is correct only while that seed is exactly local midnight. I could find no IANA zone that skips 2000-01-01T00:00, and makeDate predates this PR (#866) — but this PR routes startOfDay, startOfMonth, endOfDay, endOfMonth and parseDate through it, which is what makes the seed load-bearing for the library's normalization primitives rather than for two grid builders. A one-line d.setHours(0, 0, 0, 0) would remove the assumption.
• Open (findings 2 and 3): years 0, above 9999, and negative years on the native path. All three are limits of the HTML value grammar or of the fixed-width read-back regexes rather than year remapping, and none is a regression from this diff.
• Verification note: reverting the five source files to 836e20b5 to re-run the new tests against pre-fix code was not permitted in this sandbox, so the "each fails on main" claim rests on the ECMAScript semantics those tests encode (new Date(19, …) → 1919; year 0 is a leap year while 1900 is not; an unpadded 19-03-04T14:30 is not a valid datetime-local value) — assertions that cannot hold through the old constructor.

🏄 Three commits deep and the early-year swell is fully ridden, brah — every new Date(19, …) reef break in the picker is cleared, coverage is glassy at 100% on both helper files, and the new tests actually bite. Only thing out of trim is the write-up on the back of the board: it still says you never paddled out for parseDate, and you did. Tidy that caption and this one is good to go.

[allxsmith]

deep-review: verify

Every open thread has a reply: fixed, with the commit, or refuted with a reason. This settles them on e4e0466.

[github-actions]

Preview Deployment

Preview URL: https://c1bdf6ea.bestax.pages.dev

[claude]

Deep review (verify) — 3 resolved · 0 open

#	Thread	Outcome	Location
1	PR body contradicted the code it described	✅ Verified fixed	bulma-ui/src/form/DateInputBase.tsx:71 (body finding, no line of its own)
2	Year 0 cannot reach either native input (🔵 Advisory)	✅ Reason accepted	bulma-ui/src/form/DateTimeInputBase.tsx:43
3	Years outside 1–9999 fall out of the native round trip (🔵 Advisory)	✅ Verified fixed + reason accepted	bulma-ui/src/form/DateTimeInputBase.tsx:63

What I checked

• Thread 1 — the rewritten body no longer says parseDate was left alone; it names parseDate as the one user-visible change to free-text entry, and lists the sites the later commits touched (daysInMonth, both native read-backs with their four-or-more-digit years, and the toIsoDateTime padding).
• Thread 2 — refuted by the PR author (live role admin): the HTML date grammar admits no year at or below zero, so there is no alternative value the serializer could write, and the behaviour choice is tracked in #902. That issue exists, is open, and names exactly this. The reason holds.
• Thread 3 — the five-digit half is genuinely fixed in e4e04660: fromIsoDateTime (DateTimeInputBase.tsx:59) and both fromIsoValue branches (DateInputBase.tsx:66,69) now match a year of four or more digits, with tests round-tripping a year-10000 native pick through the date, month and datetime-local inputs. The negative-year row and the untouched Calendar default year window are accepted as the same product decision tracked in #902.
• Ran the picker suites — DateInput, DateInput.styles, DateTimeInput, dateUtils, formatters, segmentMap: 453 tests, all passing.

Overall: this pass settled threads and reviewed no commits. All three open threads are now resolved — one PR-body fix, one code fix verified against its tests, and two advisory limitations accepted as a deliberate product decision tracked in #902. Nothing of mine is left open; a reader who wants the current code reviewed afresh should ask for a fresh pass.

Residual risk: out of scope for a verify pass — no new findings were sought or raised. The one risk the settled threads leave standing is already on the record in #902: years at or below zero still cannot be carried by the native inputs, and the Calendar default year list and the YYYY token have no defined behaviour there.

🏄 Three threads paddled in clean — one patched, one coded, two waved through with a real reason and an issue number to back it. No chop left on the water; this one is good to go.

[bestax-release-bot]

🎉 This PR is included in version 5.26.3 🎉

The release is available on:

• npm package (@latest dist-tag)
• GitHub release

Your semantic-release bot 📦🚀

[bestax-release-bot]

🎉 This PR is included in version 2.25.0 🎉

The release is available on:

• npm package (@latest dist-tag)
• GitHub release

Your semantic-release bot 📦🚀

[bestax-release-bot]

🎉 This PR is included in version 4.2.13 🎉

The release is available on:

• npm package (@latest dist-tag)
• GitHub release

Your semantic-release bot 📦🚀

[bestax-release-bot]

🎉 This PR is included in version 1.14.1 🎉

The release is available on:

• npm package (@latest dist-tag)
• GitHub release

Your semantic-release bot 📦🚀