fix: localization dates not being localized correctly

[TaduJR]

Explanation of Change

• Display dates use Intl.DateTimeFormat (dateStyle / timeStyle) across CalendarPicker, DateIcon, DOB step, receipts, travel, search, per-diem, status, schedule-call, and chat travel notifications.
• getWeekStartsOn / getWeekEndsOn are locale-aware via Intl.Locale.getWeekInfo(); calendar shows the correct first day per locale.
• DOB field placeholder + selected value both localized (en → MM/DD/YYYY, de → DD.MM.YYYY, ja → YYYY/MM/DD).
• Month names render capitalized across locales (es → Enero, fr → Janvier, de → Januar).
• CalendarPicker weekday headers use weekday: 'short' (fr → lun. mar. mer.) — narrow labels were ambiguous in fr/it/pt-BR.
• formatTravelDate (chat travel notifications) now respects locale; per-diem same-day "Time" row keeps the date.

Architectural improvements:

• Strict Locale end-to-end — IntlStore eager-seeds EN at module load so getCurrentLocale(): Locale (never undefined); cascades through useLocalize().preferredLocale to every formatter signature. No ?? CONST.LOCALES.DEFAULT fallbacks left.
• LocaleContextProvider reads IntlStore via useSyncExternalStore — one re-render per locale change instead of the prior useState + useEffect-on-Onyx-flag two-tick dance.
• useNow hook (new) — AutoUpdateTime and ParticipantLocalTime previously ran their own per-second setIntervals; both now share one ref-counted minute-tick via useSyncExternalStore.

Fixed Issues

$ #69562
PROPOSAL: #69562 (comment)

Tests

Setup

A. Language

• Settings → Profile → Preferences → Language. Switch between English and Español between full passes.

B. Device timezone (OS-level — outside the app)

Set the device's timezone in the OS settings before each pass:

OS	How
iOS	Settings → General → Date & Time → turn Set Automatically off → tap Time Zone → search "Los Angeles" or "Tokyo"
Android	Settings → System → Date & time → turn off automatic → set timezone manually
macOS	System Settings → General → Date & Time → turn off "Set time zone automatically" → set city
Windows	Settings → Time & language → Date & time → turn off "Set time zone automatically" → set zone

After changing OS timezone, fully close and reopen the App so it picks up the new zone.

C. In-app timezone (separate from device timezone)

In-app timezone is configured at: Settings → Profile → Timezone

• Automatic: ON → in-app timezone mirrors the device's OS timezone.
• Automatic: OFF → you pick a timezone manually from the list (e.g. America/Los_Angeles, Asia/Tokyo, Europe/Berlin).

Tests 10, 11, 9, and R7-A explicitly require manipulating the in-app timezone.

---

Test 1 — Date Picker placeholder + selected value

Where: Settings → Profile → Personal Details → Date of birth.

1. Look at the grey placeholder inside the empty field.
2. Tap to open the calendar. Pick January 5, 2026 (or any past date).
3. Tap Save.
4. Reopen the row and read the saved value.

Expected:

• English: placeholder MM/DD/YYYY, saved value 01/05/2026.
• Spanish: placeholder DD/MM/AAAA (or DD/MM/YYYY), saved value 05/01/2026.
• Placeholder format and saved value format match (both day-first or both month-first).
• Result is identical across all device timezones (UTC−8 and UTC+9 should both show the same value).

---

Test 2 — Calendar weekday headers and month names

Where: Any date picker.

1. Open the calendar.
2. Look at the row of weekday letters above the day grid.
3. Tap the month name at the top → look at the month list.

Expected:

• English: weekday letters S M T W T F S or M T W T F S S; months read "January…".
• Spanish: localized weekday initials; months read "Enero, Febrero, Marzo…" with capitalized first letter.
• No empty cells or two columns showing the same letter ambiguously.

---

Test 3 — Calendar first day of week

1. Open any date picker.
2. Look at the leftmost weekday column header.

Expected:

• English: Monday is leftmost.
• Spanish: Monday is leftmost.
• If a Japanese build is available: Sunday is leftmost.

---

Test 4 — Travel reservations (Hotel / Flight / Car / Train)

Where: A chat with a travel booking → trip → individual reservation.

1. Open a Hotel reservation. Check Check-in and Check-out rows.
2. Open a Flight reservation. Check Departs and Arrives rows.
3. Open a Car reservation. Check Pick-up, Drop-off, Cancellation lines.
4. Open a Train reservation. Check dates + route description.

Expected:

• Dates and times in the active language.
• Date and time on the same line describe the same moment — never off-by-one-day between them. Re-verify on UTC+9 (Tokyo device): a flight stored as e.g. 2026-04-02T19:00-05:00 must show consistent date+time, not "Apr 3 at 9:00 AM" vs "Apr 2 at 9:00 AM" split across the two halves of the row.

---

Test 5 — Travel chat preview card

Where: Chat list showing a travel-room conversation.

1. Find a chat with a travel preview card.
2. Look at the date range shown.

Expected: Range uses the active language's month abbreviations. Single-day trips show one date.

---

Test 6 — Travel update messages in chat

Where: A travel chat with system notifications (ticket issued, flight changed, cancelled, etc.).

1. Find any travel notification (grey/italic system message).
2. Look at the embedded date and time.

Expected: Both render in active language and describe the same moment regardless of device timezone.

---

Test 7 — Receipt full view (EReceipt)

Where: A transaction with a receipt → tap thumbnail → view receipt.

1. Look at the date printed on the receipt page.

Expected: Date in active language (English: "January 5, 2026"; Spanish: "5 de enero de 2026"). Date does not shift across UTC−8 vs UTC+9.

---

Test 8 — Per-diem expense Time row

Where: Workspace with per-diem enabled.

1. Create a per-diem with same start and end date (today 2pm–6pm).
2. Look at the "Time" row.
3. Repeat with different start and end dates (today 9am to tomorrow 5pm).

Expected:

• Same-day case: 9:00 AM – 5:00 PM, Jan 5, 2026.
• Multi-day case: 9:00 AM, Jan 5, 2026 – 5:00 PM, Jan 6, 2026.
• Active language reflected.
• On UTC+9 device: same per-diem still shows the time you picked, in the same date you picked it on.

---

Test 9 — Custom status (Clear after) — in-app timezone sensitive

Where: Settings → Profile → Status.

Run in two sub-passes:

9a. Device TZ = UTC−8, In-app TZ = Automatic (so in-app = UTC−8)

1. Set a status. Set Clear after → Custom, pick tomorrow at 5:00 PM. Save.
2. Read the "Clear after" row.

9b. Device TZ = UTC−8, In-app TZ = Manual → Asia/Tokyo (UTC+9)

1. Settings → Profile → Timezone → toggle Automatic OFF → pick Asia/Tokyo. Save and go back.
2. Settings → Profile → Status → Clear after → Custom. Pick tomorrow at 5:00 PM. Save.
3. Read the "Clear after" row.

Expected (both sub-passes):

• The displayed time and date match what you picked in the picker, interpreted in the in-app timezone you have selected (not the device timezone).
• Open a chat with another person and verify the small status hint on the chat list row reads consistently.

---

Test 10 — Profile "Local time" row — in-app timezone sensitive

Where: Open your own profile (avatar → details) → find Local time row.

Run in two sub-passes:

10a. In-app Timezone = Automatic

1. Note the displayed time.
2. Wait ~1–2 minutes without interacting.

Expected: Time matches the device clock. Auto-updates within ~60 seconds (e.g. "2:34 PM" → "2:35 PM"). 12-hour AM/PM in English, 24-hour in Spanish.

10b. In-app Timezone = Manual Asia/Tokyo

1. Settings → Profile → Timezone → turn Automatic OFF → pick Asia/Tokyo. Save.
2. Return to your profile → Local time row.

Expected: Time now shows Tokyo wall-clock time (≈17 hours ahead of US Pacific), formatted in the active language. The displayed timezone abbreviation (e.g. JST) reflects Tokyo. Auto-update at the minute boundary still works.

---

Test 11 — Participant local time (chat header) — in-app timezone sensitive

Where: A 1:1 chat with a participant whose in-app timezone differs from yours.

Setup: You should be in (say) America/Los_Angeles. The other participant should be in Asia/Tokyo. Both timezones set via Settings → Profile → Timezone → Manual in each account.

1. Open the 1:1 chat.
2. Look at the chat header / participants section for "X's local time is …".
3. Wait ~1–2 minutes.

Expected:

• The displayed time reflects the other person's in-app timezone (e.g. Tokyo wall-clock).
• If the two timezones land you on different weekdays, the hint includes the participant's day name (e.g. "9:00 AM Tue").
• Time format follows your own active language.
• The time auto-updates at the minute boundary.

---

Test 12 — Search results date column

Where: Search → any search with dated results.

1. Observe the date column on each row.

Expected: Dates use active language's month abbreviations. Past-year rows include year, current-year typically omit it. No row shows the wrong calendar day after changing device timezone.

---

Test 13 — Wallet statements

Where: Settings → Wallet → View statement → pick a month.

1. Open any monthly statement. Observe page title / month label.

Expected: Month name fully localized.

---

Test 14 — Workspace distance rates start/end date

Where: Workspace with Date-bound mileage rate beta enabled. Workspace → Distance rates → tap a rate.

1. Look at Start date and End date rows.
2. Tap either row → opens the date editor.

Expected: Rows in active language. Editor calendar shows correct localized placeholder. Saving a date and re-opening shows the same date even after switching device timezone.

---

Test 15 — Frozen card header

Where: Settings → Wallet → Expensify Card → A frozen card.

1. Look at the "Frozen on …" subtitle/banner.

Expected: Frozen date follows the active language.

---

Test 16 — Schedule a call

Where: Any chat with the Schedule a call action.

1. Start scheduling. Pick a date in the calendar.
2. Continue to the confirmation page. Observe the date/time line.

Expected: Calendar and confirmation line both in active language. Selected date+time consistent across device timezones.

---

Test 17 — Out-of-office (Chronos) summary

Where: A chat with Chronos / OOO bot messages.

1. Find a full-day OOO summary ("X is out for 2 days, back on Mon, Jan 12").
2. Find a partial-day OOO message ("X is out 9:00 AM – 5:00 PM on Mon, Jan 5, 2026").

Expected: Both in active language, consistent date/time formatting.

---

Test 18 — Split expense date column

Where: An expense that has been split.

1. Open the expense → tap Split. Observe each row's date.

Expected: Dates in active language. No day-shift across device timezones.

---

Regression Test Cases (must pass before merge)

Each below reproduces a real bug from prior reverted attempts. They must all pass.

---

R1 — Merge expense: no crash on confirmation page (#80013)

1. In a workspace chat, create two expenses.
2. Open the expense report → select both via checkboxes.
3. Tap dropdown → Merge.
4. Pick a field from either expense → Next.

Expected: Merge confirmation page opens normally. No crash, no white screen.

---

R2 — Merge expense: opening merged expense does not crash (PR #69945)

1. Complete the merge from R1.
2. Open the resulting merged expense from the report.

Expected: Detail page opens. Date row renders. No crash.

---

R3 — Date picker: picked date matches saved date (#76646)

Run on iOS App, Windows Chrome, and macOS Chrome/Safari.

1. Settings → Profile → Personal Details → Date of birth.
2. Pick January 15, 2000 → Save.
3. Reopen and read.

Expected: Saved date is exactly Jan 15, 2000. Not Jan 14, not Jan 16.

Run this also under UTC+9 device timezone. The result must still be Jan 15.

---

R4 — Date picker: same-day select on Monday-start calendar (PR #69945 deploy-blocker)

Active language: English or Spanish.

1. Open any date picker.
2. Note today's day-name.
3. Tap today (highlighted cell). Tap Save. Reopen.

Expected: Saved date is today. Every column in the grid saves the date its header letter says (M-cell → Monday, T-cell → Tuesday, etc.). Repeat for several weekdays.

---

R5 — Bank account DOB placeholder shows locale format (#80011)

Active language: English, Windows Chrome.

1. Workspaces → (any workspace) → Workflows → Add bank account → Connect manually.
2. Step through to Personal info → Date of birth.
3. Look at the placeholder before tapping.

Expected: Placeholder reads MM/DD/YYYY. Never YYYY-MM-DD. Switch to Spanish and re-check.

---

R6 — Split expense: opening a split does not crash on Android (#76643)

Run on Android (original repro: Redmi Note 10s, Android 13).

1. Create a split expense.
2. Tap the split in chat to open it.

Expected: Detail page opens. Dates render in active language. No crash.

---

R7 — No day-shift across the app (#80024) — timezone-critical

Setup: Device language English. Run all three parts twice: once with device timezone US Pacific (UTC−08:00), then again with device timezone Asia/Tokyo (UTC+09:00). Test on iOS App and Windows Chrome.

R7-A — Status:

This also tests in-app timezone interaction.

1. Settings → Profile → Timezone: keep Automatic ON (so in-app TZ = device TZ for this part).
2. Settings → Profile → Status → Clear after → Custom.
3. Pick January 25, 2026 at a specific time → Save.
4. Read the "Clear after" row.

Expected (both Pacific and Tokyo passes): Shows the date and time you picked. Never Jan 24 in one pass and Jan 25 in the other.

Then repeat R7-A with in-app Timezone set manually to Europe/Berlin (UTC+01:00) — the saved value should now reflect Berlin wall-clock, not device wall-clock.

R7-B — Date of birth:

1. Settings → Profile → Personal Details → Date of birth.
2. Pick March 10, 1995 → Save → reopen.

Expected (both Pacific and Tokyo passes): Shows March 10, 1995 (or 03/10/1995). Not March 9, not March 11.

R7-C — Company cards transaction start date:

1. Workspaces → (any with company cards) → Company cards.
2. Tap an unassigned card → Assign to a user.
3. In the wizard, pick Transaction start date = February 1, 2026.
4. Continue, then return and re-read.

Expected (both passes): Saved date is Feb 1, 2026.

• Verify that no errors appear in the JS console

Offline tests

Same as tests

QA Steps

// TODO: These must be filled out, or the issue title must include "[No QA]."
Same as tests

• Verify that no errors appear in the JS console

PR Author Checklist

• I linked the correct issue in the ### Fixed Issues section above
• I wrote clear testing steps that cover the changes made in this PR
  • I added steps for local testing in the Tests section
  • I added steps for the expected offline behavior in the Offline steps section
  • I added steps for Staging and/or Production testing in the QA steps section
  • I added steps to cover failure scenarios (i.e. verify an input displays the correct error message if the entered data is not correct)
  • I turned off my network connection and tested it while offline to ensure it matches the expected behavior (i.e. verify the default avatar icon is displayed if app is offline)
  • I tested this PR with a High Traffic account against the staging or production API to ensure there are no regressions (e.g. long loading states that impact usability).
• I included screenshots or videos for tests on all platforms
• I ran the tests on all platforms & verified they passed on:
  • Android: Native
  • Android: mWeb Chrome
  • iOS: Native
  • iOS: mWeb Safari
  • MacOS: Chrome / Safari
  • MacOS: Desktop
• I verified there are no console errors (if there's a console error not related to the PR, report it or open an issue for it to be fixed)
• I verified there are no new alerts related to the canBeMissing param for useOnyx
• I followed proper code patterns (see Reviewing the code)
  • I verified that any callback methods that were added or modified are named for what the method does and never what callback they handle (i.e. toggleReport and not onIconClick)
  • I verified that comments were added to code that is not self explanatory
  • I verified that any new or modified comments were clear, correct English, and explained "why" the code was doing something instead of only explaining "what" the code was doing.
  • I verified any copy / text shown in the product is localized by adding it to src/languages/* files and using the translation method
    • If any non-english text was added/modified, I used JaimeGPT to get English > Spanish translation. I then posted it in #expensify-open-source and it was approved by an internal Expensify engineer. Link to Slack message:
  • I verified all numbers, amounts, dates and phone numbers shown in the product are using the localization methods
  • I verified any copy / text that was added to the app is grammatically correct in English. It adheres to proper capitalization guidelines (note: only the first word of header/labels should be capitalized), and is either coming verbatim from figma or has been approved by marketing (in order to get marketing approval, ask the Bug Zero team member to add the Waiting for copy label to the issue)
  • I verified proper file naming conventions were followed for any new files or renamed files. All non-platform specific files are named after what they export and are not named "index.js". All platform-specific files are named for the platform the code supports as outlined in the README.
  • I verified the JSDocs style guidelines (in STYLE.md) were followed
• If a new code pattern is added I verified it was agreed to be used by multiple Expensify engineers
• I followed the guidelines as stated in the Review Guidelines
• I tested other components that can be impacted by my changes (i.e. if the PR modifies a shared library or component like Avatar, I verified the components using Avatar are working as expected)
• I verified all code is DRY (the PR doesn't include any logic written more than once, with the exception of tests)
• I verified any variables that can be defined as constants (ie. in CONST.ts or at the top of the file that uses the constant) are defined as such
• I verified that if a function's arguments changed that all usages have also been updated correctly
• If any new file was added I verified that:
  • The file has a description of what it does and/or why is needed at the top of the file if the code is not self explanatory
• If a new CSS style is added I verified that:
  • A similar style doesn't already exist
  • The style can't be created with an existing StyleUtils function (i.e. StyleUtils.getBackgroundAndBorderStyle(theme.componentBG))
• If new assets were added or existing ones were modified, I verified that:
  • The assets are optimized and compressed (for SVG files, run npm run compress-svg)
  • The assets load correctly across all supported platforms.
• If the PR modifies code that runs when editing or sending messages, I tested and verified there is no unexpected behavior for all supported markdown - URLs, single line code, code blocks, quotes, headings, bold, strikethrough, and italic.
• If the PR modifies a generic component, I tested and verified that those changes do not break usages of that component in the rest of the App (i.e. if a shared library or component like Avatar is modified, I verified that Avatar is working as expected in all cases)
• If the PR modifies a component related to any of the existing Storybook stories, I tested and verified all stories for that component are still working as expected.
• If the PR modifies a component or page that can be accessed by a direct deeplink, I verified that the code functions as expected when the deeplink is used - from a logged in and logged out account.
• If the PR modifies the UI (e.g. new buttons, new UI components, changing the padding/spacing/sizing, moving components, etc) or modifies the form input styles:
  • I verified that all the inputs inside a form are aligned with each other.
  • I added Design label and/or tagged @Expensify/design so the design team can review the changes.
• If a new page is added, I verified it's using the ScrollView component to make it scrollable when more elements are added to the page.
• I added unit tests for any new feature or bug fix in this PR to help automatically prevent regressions in this user flow.
• If the main branch was merged into this PR after a review, I tested again and verified the outcome was still expected according to the Test steps.

Screenshots/Videos

Android: Native

Android: mWeb Chrome

iOS: Native

iOS: mWeb Safari

MacOS: Chrome / Safari

Mac-Chrome.mp4

[melvin-bot]

Hey! I see that you made changes to our Form component. Make sure to update the docs in FORMS.md accordingly. Cheers!

[melvin-bot]

@situchan Please copy/paste the Reviewer Checklist from here into a new comment on this PR and complete it. If you have the K2 extension, you can simply click: [this button]

[codecov]

Codecov Report

✅ Changes either increased or maintained existing code coverage, great job!

Files with missing lines	Coverage Δ
src/CONST/index.ts	94.81% <ø> (ø)
src/Expensify.tsx	87.39% <100.00%> (+0.10%)	⬆️
src/components/DateIcon.tsx	100.00% <100.00%> (ø)
...s/DatePicker/CalendarPicker/generateMonthMatrix.ts	100.00% <100.00%> (ø)
src/components/DatePicker/CalendarPicker/index.tsx	96.59% <100.00%> (+0.02%)	⬆️
src/components/DatePicker/index.tsx	53.70% <100.00%> (+0.43%)	⬆️
src/components/LocaleContextProvider.tsx	91.83% <100.00%> (+0.60%)	⬆️
...ponents/ReportActionItem/ChronosOOOListActions.tsx	43.75% <100.00%> (ø)
...m/TransactionPreview/TransactionPreviewContent.tsx	82.45% <100.00%> (ø)
...rc/components/ReportActionItem/TripRoomPreview.tsx	56.75% <100.00%> (ø)
... and 48 more
... and 10 files with indirect coverage changes

[MelvinBot]

PR Review

Well-executed migration from date-fns format strings to Intl.DateTimeFormat. The IntlStore / useSyncExternalStore architecture is clean, the useNow hook is correctly implemented, and locale threading is consistent across callers. A few items worth addressing:

Issues to fix

1. Mock type mismatch — src/languages/__mocks__/IntlStore.ts:7
The mock declares currentLocale: Locale | undefined while production now uses Locale (non-optional). This means getCurrentLocale() in the mock has an inferred return type of Locale | undefined, which doesn't match production. Tests could pass while incorrectly handling undefined. Change to Locale (no | undefined).

2. getStablePerDiemMerchantDateRange byte-stability concern — src/libs/DateUtils.ts
The comment says output "must stay byte-stable across user-locale changes." The locale is correctly pinned, but switching from format(date, 'MMM d, yyyy') (deterministic template) to Intl.DateTimeFormat('en', {dateStyle: 'medium'}) means output now depends on the platform's ICU version. iOS, Android, and web can produce subtly different strings (e.g., "Jun 5, 2025" vs "Jun. 5, 2025"). If this string is matched/compared on the backend, that's a problem.

3. datetimeToRelative still produces English-only output — src/libs/DateUtils.ts:256-260
This function accepts a locale parameter but never passes a date-fns locale to formatDistance. Relative strings like "12 minutes ago" are always English regardless of the user's locale. Pre-existing issue, but a notable omission given the PR's goal.

Suggestions (non-blocking)

4. SHORT_DATE vs SHORT_DATE_PADDED separator consistency
getLocalizedDatePlaceholder derives field ORDER from SHORT_DATE (dateStyle: 'short') but the actual display uses SHORT_DATE_PADDED ({year:'numeric', month:'2-digit', day:'2-digit'}). These can theoretically produce different separators in some locales (e.g., / vs .). Worth cross-locale testing.

5. CalendarPicker missing useMemo
monthNames, daysOfWeekLong, daysOfWeek at src/components/DatePicker/CalendarPicker/index.tsx are recalculated every render. Wrapping in useMemo with preferredLocale as dependency would avoid unnecessary array allocations.

6. getWeekStartsOn tests are ICU-dependent
The parameterized tests for ja and pt-BR expect Sunday-start via Intl.Locale.getWeekInfo(). If CI has small-icu Node builds, these fall back to Monday and fail.

What's done well

• UTC anchoring via toUTCDate/toLocalDate prevents the classic date-only-string timezone shift bug
• NNBSP stripping regex is precise — only targets space before AM/PM, preserving French/Slavic typography
• useNow hook is textbook useSyncExternalStore: stable function references, ref-counted subscriptions, monotonic minute indices, correct cleanup
• IntlStore race guard (monotonic load token) correctly handles rapid locale switches
• zh-hans narrow weekday test guards against CJK narrow-name collision — excellent edge case coverage
• Type narrowing from Locale | undefined → Locale throughout is safe now that IntlStore pre-seeds EN

[situchan]

@TaduJR you're missing native platform tests.

Please test various timezones (US timezone UTC-X, Asia timezone UTC+X)

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: e56f6b81c3

ℹ️ About Codex in GitHub

Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".

[situchan]

Regression test cases:

• Fix localization: dates not being localized correctly #69945 (comment)
• Fix localization: dates not being localized correctly #69945 (comment)
• Android - Expense-App crashes on opening split expense #76643
• Profile - Selected date in the calendar is moved back by one day #76646
• [Due for payment 2026-01-29] Bank - Date of birth field placeholder shows YYYY-MM-DD when the new format is MM/DD/YYYY #80011
• [Due for payment 2026-01-29] Expense - App crashes when reaching merge confirm page #80013
• [Due for payment 2026-01-29] Date - Wrong date (moved back by one day) displayed in date field #80024

[TaduJR]

@codex review

[chatgpt-codex-connector]

Codex Review: Didn't find any major issues. You're on a roll.

Reviewed commit: 5ee0121948

ℹ️ About Codex in GitHub

Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".

[TaduJR]

@situchan

Addressed many inconsistencies after merge main.

It's hard to keep up.

Would it be possible to finish reviewing this weekend.

Thanks!

[situchan]

Can we split into smaller PRs to avoid being reverted?

[chatgpt-codex-connector]

Codex Review: Didn't find any major issues. 👍

Reviewed commit: 74721f3f6d

ℹ️ About Codex in GitHub

Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".

[MelvinBot]

Code review

Verdict: Strong, carefully-built PR. The date/locale refactor is well-reasoned, the risky timezone paths are documented and defended, and the test coverage is substantial. I found no correctness blockers — two minor cleanups and one pre-existing edge to note. CI is green (the only red check, Check independent approval, is just the pending-reviewer gate, not a code failure).

What it does

Moves display-date formatting to Intl.DateTimeFormat with locale-aware week starts (Intl.Locale.getWeekInfo()), makes Locale strict end-to-end (IntlStore seeds EN so getCurrentLocale() is never undefined), converts LocaleContextProvider and the per-minute clock (useNow/NowStore) to useSyncExternalStore, and threads preferredLocale into every date formatter. ~85 files.

Strengths

• UTC-anchoring discipline is the right call and applied consistently: calendar-date fields (transaction date, DOB, frozen-on, billing) go through formatInUTC*/formatTransactionListDate with a 'UTC' timeZone so they never day-shift by viewer timezone, while timestamped fields format in local/zoned time. This is the core of the linked bug ([Due for payment 2026-01-29] Date - Wrong date (moved back by one day) displayed in date field #80024) and it's handled deliberately.
• Render-path safety: formatIntl degrades on Invalid Date (→ '') and bad-timezone (→ UTC retry) instead of throwing, since these callers have no error boundary.
• IntlStore.load() is race-safe via the monotonic loadToken — a superseded in-flight load won't commit a stale locale.
• The prior Codex/bot comments look addressed: formatTravelDate now formats both halves in local time (consistent moment), the cancellation-offset regex is gated on :, weekday headers use short labels, and MS_PER_MINUTE is extracted.

Findings

1. Dead code — getDaysOfWeekNarrow is unused (minor, DRY).
DateUtils.ts:401-403 is exported and has a dedicated unit test, but no production code calls it — CalendarPicker/index.tsx:222 uses getDaysOfWeekShort (the intended resolution of the earlier "use short, not narrow" review comment). The narrow helper appears to be a leftover from that earlier approach. Remove it + its test, or wire it up if it's meant to be used somewhere. The checklist claims "all code is DRY", so worth resolving before merge.

2. getFormattedCancellationDate comment overstates date-only support (minor).
DateUtils.ts:958 — the :-gate comment says it supports a date-only value like '2026-04-19', but that branch produces canonicalIso = '2026-04-19Z', which is an Invalid Date (a Z designator isn't valid on a bare date), so formatIntl returns ''. It's not a live bug — every real caller (TripReservationUtils.getCancellationDeadline) passes a full ISO string with an explicit offset — but the comment claims a case the code doesn't actually handle. Either drop the date-only claim or handle it explicitly.

3. Pre-existing (not a regression), flagging for a follow-up.
In src/pages/settings/Subscription/CardSection/utils.ts, fromUnixTime(endDate).toUTCString() → formatInUTCToLong(...) returns '' because date-fns-tz's parser can't read the RFC-2822 string toUTCString() emits. The old formatWithUTCTimeZone used the same parser and had the same behavior, so this PR doesn't introduce it — but since you're touching the line, it may be worth passing an ISO string / Date instead so the billing date actually renders.

Can't verify here

The testing session couldn't sign in, so I reviewed statically only. Two things warrant the manual/visual QA you documented: (a) whether the 3-char short weekday labels (e.g. fr lun.) fit the narrow day-column cells without overflow/truncation across locales, and (b) the timezone-sensitive display cases — the R7 regression set and Tests 9–11 (in-app vs device timezone) are the highest-risk surfaces given the breadth of this change.

[MelvinBot]

Regression hunt

Bottom line: No functional regressions found — no day-shifts, crashes, broken selection, clock, or locale-loading regressions. The behavioral rewrites (shared minute clock, useSyncExternalStore locale store, locale-aware calendar week-start) preserve observable behavior. What does change is a set of visible English (default-locale) date format strings — almost all of them intended consequences of this localization fix, but users who never switched language will see them, so they're worth a conscious sign-off. Two items warrant a design/QA eyeball. This is static analysis (the test session couldn't sign in), so the two flagged items should be eyeballed live.

Behavioral / lifecycle — all clean

Details

• Clock cadence (useNow/NowStore replacing per-second setInterval): Neither AutoUpdateTime nor ParticipantLocalTime ever displayed seconds — both render HH:mm, and the old code's re-render was already effectively per-minute. First paint is immediate (getSnapshot() returns new Date()), and the shared interval is ref-counted + cleared on last unsubscribe (no leak). Equivalent behavior, cheaper.
• Calendar week-start: en is pinned to Monday (getWeekStartsOn('en')=1), same as before. Header row and day-cell matrix both derive from the same getWeekStartsOn(locale) source, so columns stay aligned for every locale — no wrong-column-selection risk.
• Locale loading / raw-key flash: translate() returns the raw key when the cache is empty, but the splash stays gated on RAM_ONLY_ARE_TRANSLATIONS_LOADING until the en chunk resolves (Expensify.tsx:144), and currentLocale only flips after the chunk loads — so no "common.save"-style first paint. The useSyncExternalStore version faithfully replaces the old useState+useEffect sync.
• useOnyx/dependency-array changes (added preferredLocale deps in the Search date components + TransactionPreviewContent) are staleness fixes, not regressions.
• DateOfBirthStep removed line just drops a hardcoded placeholder so the field uses the locale-derived placeholder — intended.

Visible English format changes (intended, but confirm the design sign-off covers en)

These are correct-per-the-localization-goal and mostly documented in your Tests section, but they change what an English user sees today:

• DatePicker field + placeholder (DatePicker/index.tsx:230-233): value 2026-01-05 → 01/05/2026, placeholder YYYY-MM-DD → MM/DD/YYYY. (This is the fix — R5.)
• Custom status "until" (DateUtils.ts:635): 07-01 5:34 PM → Jul 1 5:34 PM; other-year 2023-07-01 … → Jul 1, 2023 ….
• Status "clear after" description (DateUtils.ts:599): 2023-05-16 11:10 PM → May 16, 2023, 11:10 PM.
• Per-diem time row (PerDiemRequestUtils.ts:229): re-laid-out to 11:10 PM – 11:40 PM, May 16, 2023 (same-day) — matches Test 8.

All high-traffic surfaces (search/transaction date cells, expense rows, travel ranges, EReceipt, chat timestamps, wallet, frozen card, distance rates) render byte-identical to before in en — verified against the CONST.DATE tokens vs the new Intl presets.

Worth an eyeball before merge

1. Calendar weekday header changed for en too (P2). CalendarPicker/index.tsx:222,371: the header went from single letters M T W T F S S to 3-char labels Mon Tue Wed … (getDaysOfWeekShort). Intended per the PR description (narrow labels collide in fr/it/pt-BR), but it's a visible change for English users, and the purpose-built getDaysOfWeekNarrow helper (single letters, exactly the old en look) was added + unit-tested yet left unused. Confirm the design team signed off on 3-letter headers for en specifically, and remove getDaysOfWeekNarrow if it's truly not wanted. Also worth checking the labels don't wrap in the narrow day-columns on the smallest screens / longest locales (pt-BR "sáb.") — the header Text has no numberOfLines guard.
2. Flight "Departs" time loses its leading zero (P3, cosmetic). DateUtils.ts:907: 08:00 AM → 8:00 AM (only the flight case; hotel/car/train already used single-h). Arguably more en-correct, just noting the inconsistency vs the old flight rendering.

[situchan]

Please fix conflict.
I'll try to finish review during weekend.
Btw see #91569 (comment)

[TaduJR]

Can we split into smaller PRs to avoid being reverted?

@situchan

No we can't they are tightly coupled.

[melvin-bot]

Hey, I noticed you changed src/languages/en.ts in a PR from a fork. For security reasons, translations are not generated automatically for PRs from forks.

If you want to automatically generate translations for other locales, an Expensify employee will have to:

1. Look at the code and make sure there are no malicious changes.
2. Run the Generate static translations GitHub workflow. If you have write access and the K2 extension, you can simply click: [this button]

Alternatively, if you are an external contributor, you can run the translation script locally with your own OpenAI API key. To learn more, try running:

npx bun ./scripts/generateTranslations.ts --help

Typically, you'd want to translate only what you changed by running npx bun ./scripts/generateTranslations.ts --compare-ref main

[github-actions]

⚠️ This PR is possibly changing native code and/or updating libraries, it may cause problems with HybridApp. Please check if any patch updates are required in the HybridApp repo and run an AdHoc build to verify that HybridApp will not break. Ask Contributor Plus for help if you are not sure how to handle this. ⚠️