[Due for payment 2026-10-12] [$175] Year not sorted from recent in create expense flow

[m-natarajan]

If you haven’t already, check out our contributing guidelines for onboarding. To join our Slack channel, fill out this form.

---

Version Number: 9.4.95-0
Reproducible in staging?: Y
Reproducible in production?: Y
If this was caught during regression testing, add the test name, ID and link from BrowserStack:
Email or phone of affected tester (no customers):
Logs: https://stackoverflow.com/c/expensify/questions/4856
Expensify/Expensify Issue URL:
Issue reported by: @AndrewGable
Slack conversation (hyperlinked to channel name): #Product

Action Performed:

1. Click on the global + > Create Expense
2. Click on the Date field > Year
3. Observe the sorting order of the years

Expected Result:

The sorting order should be
2026 (Selected by default)
2025
2024
2023

Actual Result:

2026 (Selected by default)
2126
2125
2124

Workaround:

Unknown

Platforms:

Select the officially supported platforms where the issue was reproduced:

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

Screenshots/Videos

View all open jobs on GitHub

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022104700738984088911
• Upwork Job ID: 2104700738984088911
• Last Price Increase: 2026-09-28

Issue Owner

Current Issue Owner: @ikevin127

[MelvinBot]

Updated 2026-09-30: Corrected based on feedback from AndrewGable and marufsharifi.

Proposal

Please re-state the problem that we are trying to solve in this issue.

In the date picker's year list, the selected year (2026) is pinned to the top, which is intended. The years after it should be in order: 2027, 2028, 2029. Instead they read 2126, 2125, 2124.

What is the root cause of that problem?

Move current year/month to top in the calendar pickers sorts every year newest-first, then pins the selected year to the top (YearPickerModal.tsx:42-43). moveInitialSelectionToTop only moves the selected item, so the rest keep the newest-first order (SelectionListOrderUtils.ts:3-22).

The year list runs from CURRENT_YEAR - 100 to CURRENT_YEAR + 100 (CalendarPicker/index.tsx:108-117). So the row right after the pinned year is always the largest year, 2126.

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

Keep the pin. Change only the order of the remaining years in YearPickerModal:

1. Selected year first (already done by the pin).
2. Later years in ascending order: 2027, 2028, 2029, …
3. Earlier years after that, nearest first: 2025, 2024, …

Keep the current newest-first order when the list is under CONST.STANDARD_LIST_ITEM_LIMIT, because the pin doesn't apply there.

Update YearPickerModalTest.tsx. With buildYears(2014, 14) and 2020 selected, assert the list reads 2020, 2021 … 2027, 2019 … 2014. Also assert that search keeps 2020 first.

What alternative solutions did you explore? (Optional)

• Pure ascending sort after the pin. The row after 2026 would be 1926, not 2027.
• Limit the year list to minDate/maxDate (in my first version). The expense date step sets maxDate to one year from today (DynamicIOURequestStepDate.tsx:218). The list would then drop 2028 and 2029, which the expected order includes. I removed it from the fix.
• Remove the pin. Design confirmed the pin is intended in this comment.

Investigation notes

• Placing earlier years after the later years is my choice. The expected order only lists later years. If you want earlier years in ascending order instead (2026, 2027 … 2126, 1926 … 2025), it's a one-line change to the sort.
• Confidence: high. The code fully explains the 2026 → 2126 → 2125 order. I didn't reproduce it in a browser.

---

Next Steps for Contributor+ team:
To accept: @MelvinBot implement [this](https://github.com/Expensify/App/issues/102474#issuecomment-5879927844) to create a draft PR.
To refine: @MelvinBot <your feedback>
To reject: Explain why you are rejecting Melvin's proposal.

[melvin-bot]

Triggered auto assignment to Contributor-plus team member for initial proposal review - @ikevin127 (External)

[melvin-bot]

Job added to Upwork: https://www.upwork.com/jobs/~022104700738984088911

[franklincg]

Proposal

Root cause

YearPickerModal sorts the complete year list newest-first and then pins the selected year. With 2026 selected, pinning only moves 2026 to index 0; the remaining list still starts at the maximum year, so the UI becomes 2026, 2126, 2125....

Fix

Keep the selected year pinned, but change only the ordering of the remaining items:

1. selected year first;
2. later years in ascending order: 2027, 2028, 2029...;
3. earlier years after that, nearest first: 2025, 2024....

Do not change the global year range or clamp it to minDate / maxDate as part of this issue. That would be a broader behavioral change and would remove years that the clarified requirement explicitly expects to remain available.

Validation

Update YearPickerModal coverage to verify:

• a middle selection renders selected -> future ascending -> past descending;
• the selected year stays first when searching;
• behavior near either end of the supplied year list remains correct;
• existing navigation/range behavior is unchanged.

This keeps the patch scoped to the ordering regression/requirement only and avoids coupling it to unrelated date-bound semantics.

[bonnhatnguyen]

Proposal

Please re-state the problem that we are trying to solve in this issue.

In the Create Expense flow, when opening the Date picker and selecting a Year, the selected year (e.g., 2026) is pinned at the top, but the subsequent items jump to the maximum future year (2126, 2125, 2124...) instead of displaying the most recent past years (2025, 2024, 2023...).

What is the root cause of that problem?

In PR #101187 ("Move current year/month to top in the calendar pickers"):

1. YearPickerModal.tsx receives the complete year list from CalendarPicker/index.tsx (which generates years spanning [CURRENT_YEAR - 100, CURRENT_YEAR + 100], i.e., 1926 to 2126).
2. In YearPickerModal.tsx (lines 42–43), the list is sorted in descending order (b.value - a.value), resulting in [2126, 2125, ..., 2026, 2025, ..., 1926].
3. Then moveInitialSelectionToTop moves the selected year (2026) to index 0.
4. Because the remaining elements retain their descending order starting from the maximum boundary, the item immediately following the pinned selected year is 2126, followed by 2125, 2124...
5. In addition, CalendarPicker/index.tsx generates the years array strictly between CONST.CALENDAR_PICKER.MIN_YEAR and CONST.CALENDAR_PICKER.MAX_YEAR (lines 108–117), ignoring the minDate and maxDate props passed by DynamicIOURequestStepDate.tsx (where maxDate is bounded to one year in the future via addYears(new Date(), 1)).

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

1. In src/components/DatePicker/CalendarPicker/YearPickerModal.tsx:

   • Order the year items around the selected year so that the selected year is first, followed by earlier years in descending order (2025, 2024, 2023...), and finally future years:

   const selectedYearNum = Number(currentYear);
   const earlierYears = years.filter((year) => Number(year.value) < selectedYearNum).sort((a, b) => Number(b.value) - Number(a.value));
   const futureYears = years.filter((year) => Number(year.value) > selectedYearNum).sort((a, b) => Number(a.value) - Number(b.value));
   const sortedYears = selectedYearItem ? [selectedYearItem, ...earlierYears, ...futureYears] : [...earlierYears, ...futureYears];

   This guarantees that the user immediately sees 2026, 2025, 2024, 2023... when opening the year picker, which matches the natural chronological expectation for expense date selection.

2. In src/components/DatePicker/CalendarPicker/index.tsx:

   • Derive minYear and maxYear from minDate.getFullYear() and maxDate.getFullYear(), clamped to [CONST.CALENDAR_PICKER.MIN_YEAR, CONST.CALENDAR_PICKER.MAX_YEAR].
   • Build the years list within this clamped range so that unselectable out-of-range future years (like 2126 for an expense date) are excluded.
   • Use these boundaries consistently in moveToPrevYear, moveToNextYear, moveToPrevMonth, and moveToNextMonth.

3. In tests/unit/YearPickerModalTest.tsx:

   • Update and add unit tests verifying that with a selected year (e.g., 2026), the resulting rendered list begins with 2026, 2025, 2024... rather than jumping to 2126.

What alternative solutions did you explore? (Optional)

• Reverting moveInitialSelectionToTop and restoring scroll-to-index: Explored and rejected because pinning the pre-selected item to the top is a unified UX pattern established across the app in issue Move pre-selected list items to top of list throughout the app #69184.
• Only bounding by minDate/maxDate without partitioned sorting: If a date picker allows future dates (e.g., up to 2027), without the partitioned sorting, 2027 would still precede 2025 (2026, 2027, 2025...), breaking the primary use case of selecting recent past dates. Combining partitioned sorting with boundary clamping provides the most robust and intuitive UX.

Contributor details
Your Expensify account email: bonnhatnguyen0@gmail.com
Upwork Profile Link: https://www.upwork.com/freelancers/~0139ed4098bdc50182

[melvin-bot]

✅ Contributor details stored successfully. Thank you for contributing to Expensify!

[bconnnnn]

I traced this to the ordering added in #101187.

YearPickerModal sorts the full year range newest-first and only then pins the selected year to the top. Since the range includes future years up to 2126, selecting 2026 gives:

2026, 2126, 2125, 2124, ...

I’d change the ordering around the selected year instead:

selected year -> previous years descending -> future years ascending

So 2026 becomes:

2026, 2025, 2024, 2023, ... 2027, 2028, ...

That keeps the selected year pinned, keeps valid future years available, and matches the “most recent years first” behavior the picker is trying to provide.

I’d add tests for a current-year selection, a year in the middle of the allowed range, and min/max bounded calendars so we don’t accidentally expose years outside the caller’s range.

[bconnnnn]

Proposal

Please re-state the problem that we are trying to solve in this issue.

In the Create Expense date picker, opening the year list with 2026 selected shows 2026 followed by 2126, 2125, and 2124 instead of the immediately preceding years 2025, 2024, and 2023.

What is the root cause of that problem?

CalendarPicker creates a year list spanning the global calendar bounds, currently the current year plus or minus 100. YearPickerModal sorts that entire list newest-first and then moves the initially selected year to the top. Moving 2026 to index 0 leaves the rest of the descending list in place, so the next item is still the maximum year, 2126. Date-selection bounds do not change this list ordering.

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

Build the displayed order around the year frozen when the modal opens: selected year first, years before it in descending order, then years after it in ascending order. For 2026 the first rows would be 2026, 2025, 2024, 2023, with future years still available after the past years. Keep the existing year range and date-selection bounds unchanged.

Update YearPickerModalTest.tsx to assert this order for a middle selection, verify the selected year remains first in search results, and cover selections near either end of the provided list.

What alternative solutions did you explore? (Optional)

Restricting the year list to a caller's minDate/maxDate would be a broader behavior change and still would not define the required ordering around the selected year. Removing the selected-year pin would undo the intended selected-at-top behavior.

[jawad-erfani]

@ikevin127, Besides this #101187 comment, i think it is expected and not a bug

[marufsharifi]

@ikevin127 This is expected behavior, it was introduced intentionally in #101187, which moves the currently-selected item to the top of long lists.
The intended behavior was confirmed by design here: #101187 (comment) (whatever is currently selected floats to the top, for long lists). I think we can close the issue as expected . thanks