Reports- In Custom date range, "To" option is disabled

[lanitochka17]

If you haven’t already, check out our contributing guidelines for onboarding and email contributors@expensify.com to request to join our Slack channel!

---

Version Number: v9.3.52-0
Reproducible in staging?: Yes
Reproducible in production?: N/A - new feature, doesn't exist in prod
If this was caught during regression testing, add the test name, ID and link from BrowserStack: #85313
Email or phone of affected tester (no customers): testpayment935@gmail.com
Issue reported by: Applause Internal Team
Bug source: Pull Request QA execution
Device used: Windows 11 pro /Chrome
App Component: Chat Report View

Action Performed:

1. Navigate to staging.new.expensify.com
2. Go to reports page > Date > Custom range
   3 .For From calendar - Choose year 2027 and April 1
3. For To calendar - Choose year 2027 and April 2
4. Click Apply
5. Go to date > Custom range again
6. Try to change year in To calendar

Expected Result:

To calendar can change year at anytime.

Actual Result:

Unable to change year after applying and going back to change.

Workaround:

Unknown

Platforms:

• Android: App
• Android: mWeb Chrome
• iOS: App
• iOS: mWeb Safari
• iOS: mWeb Chrome
• Windows: Chrome
• MacOS: Chrome / Safari

Screenshots/Videos

Bug7120189_1775162336475.bandicam_2026-04-02_23-14-49-619.mp4

View all open jobs on GitHub

[melvin-bot]

You have been assigned to this deploy blocker because you recently merged this PR: #85313

[melvin-bot]

💬 A slack conversation has been started in #expensify-open-source

[github-actions]

👋 Friendly reminder that deploy blockers are time-sensitive ⏱ issues! Check out the open `StagingDeployCash` deploy checklist to see the list of PRs included in this release, then work quickly to do one of the following:

1. Identify the pull request that introduced this issue and revert it.
2. Find someone who can quickly fix the issue.
3. Fix the issue yourself.

[MelvinBot]

Proposal

What is the root cause of that problem?

The "To" calendar's year picker becomes disabled because CONST.CALENDAR_PICKER.MAX_DATE is defined as current date + 1 year (~April 2027). When the user selects a "From" date in 2027, the "To" calendar receives minDate = fromDate (2027) and maxDate = MAX_DATE (also 2027). The year list is built from minYear to maxYear at CalendarPicker/index.tsx:81-91, producing only [2027]. The year picker button is disabled when years.length <= 1 at line 205.

The constraint comes from RangeDatePicker.tsx:48: toMinDate = parseCalendarDate(fromValue), which is passed as minDate to the "To" CalendarPicker.

What changes do you think we should make in order to solve the problem?

In RangeDatePicker.tsx, stop passing toMinDate as minDate to the "To" CalendarPicker. Instead, keep CONST.CALENDAR_PICKER.MIN_DATE as the minDate for both calendars, so the year picker always has the full year range available. The date ordering validation (from ≤ to) should be handled at the form/apply level rather than by constraining the calendar navigation itself. This matches how fromMaxDate could similarly over-constrain the "From" calendar.

Alternatively, if the constraint is intentional, the MAX_DATE constant could be extended (e.g., +2 years instead of +1) so there's always room for multiple years, but this is a workaround rather than a proper fix.

---

Next Steps for Contributor+ team: Reply with @MelvinBot implement this to create a draft PR, @MelvinBot <your feedback> to refine this analysis, or explain why you are rejecting Melvin's proposal.

[neil-marcellini]

It looks like this only happens for dates in the next year, so I don't think it needs to be a blocker for this new feature. We should fix it though.

I guess we need to decide how the UX works for it, but I kind of think we should allow the user to pick any calendar date on both of the calendars. If from is greater than to, when they go to apply it, we should show an error and force the user to fix it.

Or we need to make the min date for "To" update as soon as it's set for "From", not only once the range is applied.

@btkcodedev can you please work on a solution?

2026-04-02_14-43-21.mp4