[Due for payment 2026-01-29] Date - Wrong date (moved back by one day) displayed in date field

[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.5-0
Reproducible in staging?: Yes
Reproducible in production?: No
If this was caught during regression testing, add the test name, ID and link from BrowserStack: Exploratory around #78251
Email or phone of affected tester (no customers): kiatest.78+ck118261@gmail.com
Issue reported by: Applause Internal Team
Bug source: Exploratory - Significant User Experience Deterioration
Device used: Windows 11/Chrome, iPhone 16/iOS 18.7.1
App Component: User Settings

Action Performed:

Precondition: User is located in US & current date is 01/20/2026

1. Navigate to staging.new.expensify.com
2. Go to Profile >> Status >> Under Clear after, select Custom.
3. Open the Date picker.
4. Select a different date
5. Observe date in date field is moved back by one day
6. Scroll down to Private section >> Date of birth field
7. Select any year/date
8. Observe date in date field is moved back by one day
9. Save it & observe incorrect date get saved
10. Repeat steps in Company cards page assigning card to user
11. Select transaction start date & observe incorrect date get displayed in date field

Expected Result:

Same date selected in date picker should reflect in date field. Date should not be moved back by one day in date field

Actual Result:

Wrong date (moved back by one day) displayed in date field

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7054269_1768936948671.505.mp4

View all open jobs on GitHub

Issue Owner

Current Issue Owner: @garrettmknight

[melvin-bot]

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

[melvin-bot]

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

[melvin-bot]

Triggered auto assignment to @garrettmknight (Bug), see https://stackoverflow.com/c/expensify/questions/14418 for more details. Please add this bug to a GH project, as outlined in the SO.

[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.

[lanitochka17]

Production:

Recording.4767.mp4

[OSBotify]

🔍 Investigation Summary

Classification: Frontend bug
Causing PR: #78251 - "Fix localization: dates not being localized correctly" by @sofi-a (High confidence)
Related Issues: None

Recommendation: REVERT

PR #78251 introduced a timezone conversion bug in the CalendarPicker component. The code attempts to "avoid timezone issues" by converting dates to UTC, but this actually CAUSES the reported issue where selected dates are moved back by one day.

Labels: No label changes needed - keeping DeployBlockerCash as this is a frontend bug affecting the App deploy.

📋 Detailed Analysis

Evidence

• Bug is reproducible only in staging (v9.3.5-0), not in production
• Issue was discovered during exploratory testing around PR Fix localization: dates not being localized correctly  #78251
• Bug affects multiple date pickers: Status clear date, Date of birth, Company card transaction dates
• Affects users in timezones west of UTC (confirmed with Windows/Chrome and iOS devices)

Verification

The bug is in src/components/DatePicker/CalendarPicker/index.tsx lines 108-111:

const onDayPressed = (day: number) => {
    setCurrentDateView((prev) => {
        // convert to UTC to avoid timezone issues
        const date = new Date(Date.UTC(prev.getFullYear(), prev.getMonth(), prev.getDate()));
        const newCurrentDateView = setDate(date, day);
        onSelected?.(format(new Date(newCurrentDateView), CONST.DATE.FNS_FORMAT_STRING));
        return newCurrentDateView;
    });
};

PR #78251 modified this file and introduced the UTC conversion code (lines 108-109).

Root Cause

The code creates a UTC timestamp, then formats it back to local time:

1. User selects January 20, 2026
2. Code creates UTC date: Date.UTC(2026, 0, 20) → 2026-01-20 00:00:00 UTC
3. For users in PST (UTC-8), this UTC timestamp represents 2026-01-19 16:00:00 PST
4. When format() converts to local time for display, it shows 2026-01-19

The "convert to UTC to avoid timezone issues" comment is ironic - this conversion IS the timezone issue. Dates should remain in local time throughout the selection process.

Impact

This affects all date picker usage across the app for users in western timezones (Americas, parts of Pacific). The selected date is consistently off by one day, causing:

• Wrong status clear dates
• Incorrect date of birth values saved to user profiles
• Wrong transaction start dates for company cards