[$175] Rail trip date does not include a year in the trip room/ rail details

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

Version Number: 9.5.33-0
Reproducible in staging?: Yes
Reproducible in production?: Yes
If this was caught during regression testing, add the test name, ID and link from BrowserStack: #105863
Email or phone of affected tester (no customers): applausetester+ii_1905@applause.expensifail.com
Issue reported by: Applause Internal Team
Bug source: Pull Request QA execution
Device used: MacBook Air 26.6.2 Chrome, iPhone 15 iOS 26.6.1
App Component: Money Requests

Action Performed:

Preconditions: as an expensifail account with the Travel enabled in the workspace, book a railroad one way trip

Go to the workspace chat, open the trip room
Open the trip details with the header "Rail details"
Observe the Date field

Expected Result:

The date in the Rail details looks like Monday, December 14, 2026

Actual Result:

The date in the Rail Details looks like Monday, Dec 14

Workaround:

Unknown

Platforms:

Screenshots/Videos

Bug7307159_1793994314603.Rail_trip_date.mp4

View all open jobs on GitHub

Applause Internal Information
Exported by: Chandana Kiran
Bug ID: 7307159

Upwork Automation - Do Not Edit

Upwork Job URL: https://www.upwork.com/jobs/~022118813454025597442
Upwork Job ID: 2118813454025597442
Last Price Increase: 2026-11-06

While Applause doesn't embed attachments for this bug, here are the links for quick view:
https://platform.applause.com/services/links/v1/external/585709df890976864774ea121b7397e55ca7212e9bdd93213284c2ae838459f1

@ZhenjaHorbach

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

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

🤖 Web test steps verification results: ⚠️ partial

The test account shows “No workspaces yet,” so no Travel-enabled workspace or booked rail trip was available. No bookings or fixtures were created.

Step	Status
Open workspace chat and trip room Blocked: account has no workspaces.	⚠️
Open “Rail details” Required workspace and booked trip are unavailable.	⚠️
Verify full month and year Rail details could not be reached; live reproduction remains unverified.	⚠️

Proposal

Confidence: Medium — source code explains the reported output; live verification was blocked.

What is the root cause of that problem?

Rail details uses a compact transport-date formatter. For current-year trips, it explicitly selects EEEE, MMM d, producing Monday, Dec 14. Other-year dates include the year but still abbreviate the month.

Code evidence and alternatives checked

TrainTripDetails.tsx:27–53 passes the transport formatter’s date directly to the Date field.
DateUtils.ts:967–980 explicitly abbreviates the month and conditionally omits the year. A missing server year or timezone issue is not needed to explain this output.
The trip-room summary already uses the full-date helper in TripDetailsView.tsx:71–80. The confirmed code defect is therefore in the opened Rail details panel.
This behavior already existed before the linked QA PR. Localize full dates with a weekday did not introduce it.

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

Use the existing full-date formatter for the Rail details Date field only. Keep departure and arrival time formatting unchanged.

Add regression coverage for current-year and other-year departures, localized date ordering, and unchanged departure/arrival times.

What alternative solutions did you explore? (Optional)

Changing the shared transport formatter would unnecessarily affect other trip types and contradict its existing compact-format tests. A rail-specific change is safer.

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

view run

Proposal for Issue #106263 — Rail trip date does not include a year in the trip room/rail details ($175)

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

In the Rail details trip page, the Date field shows "Monday, Dec 14" (abbreviated month, no year) instead of the expected "Monday, December 14, 2026" (full month name with year).

Root cause

src/pages/Travel/TrainTripDetails.tsx line 32 calls DateUtils.getFormattedTransportDateAndHour() for the date display, then uses .date on line 51 for the Date field value.

getFormattedTransportDateAndHour() (DateUtils.ts line 930–944) formats the date as 'EEEE, MMM d' when isThisYear(date) is true — producing "Monday, Dec 14" for any trip in the current year. This is appropriate for the departure/arrival time fields (which use .hour), but the standalone Date field should show the full long-date-with-weekday format including the year.

For comparison, the trip summary view in TripDetailsView.tsx (line 79, default case for TRAIN) correctly uses DateUtils.formatToLongDateWithWeekday() which returns 'eeee, MMMM d, yyyy' = "Monday, December 14, 2026". The TrainTripDetails page should be consistent with this.

Fix

In TrainTripDetails.tsx, use DateUtils.formatToLongDateWithWeekday() for the Date field value instead of getFormattedTransportDateAndHour().date. Keep getFormattedTransportDateAndHour() for .hour since the departure/arrival time fields only need the time portion.

Specifically:

Line 51: change value={startDate.date} to value={DateUtils.formatToLongDateWithWeekday(new Date(reservation.start.date), dateFnsLocale)}

This is a one-line change, consistent with how TripDetailsView.tsx already formats TRAIN dates in its default branch.

Test plan

Book a rail trip (or use a test reservation with type 'train')
Open the trip room → Rail details
Verify the Date field shows full month name + year (e.g., "Monday, December 14, 2026")
Verify departure and arrival times still display correctly
Verify a trip booked for next year also shows the year correctly (formatToLongDateWithWeekday always includes year)

Proposal

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

When viewing a booked Rail trip in the trip room or opening Rail details, the Date field renders in the abbreviated transport format without the year (e.g., Monday, Dec 14 for current-year trips, or Monday, Dec 14, 2027 with an abbreviated month for future years) instead of the full localized long date with weekday and year (Monday, December 14, 2026). Additionally, unlike FlightTripDetails, the Date field in TrainTripDetails is missing the <MenuItem.Copy> child control.

What is the root cause of that problem?

In src/pages/Travel/TrainTripDetails.tsx:32-53, TrainTripDetails computes startDate using DateUtils.getFormattedTransportDateAndHour(new Date(reservation.start.date), dateFnsLocale) and passes startDate.date directly to the Date MenuItemField:
```
const startDate = DateUtils.getFormattedTransportDateAndHour(new Date(reservation.start.date), dateFnsLocale);
...
<MenuItemField
    name={translate('common.date')}
    value={startDate.date}
/>
```
In src/libs/DateUtils.ts:967-981, getFormattedTransportDateAndHour explicitly branches on isThisYear(date) and formats date with 'EEEE, MMM d' (omitting the year completely when isThisYear(date) is true, and using the abbreviated month MMM in all cases).
By contrast, the trip room summary in src/components/ReportActionItem/TripDetailsView.tsx:71-80 falls into the default case for CONST.RESERVATION_TYPE.TRAIN and uses DateUtils.formatToLongDateWithWeekday(new Date(reservation.start.date), dateFnsLocale), which uses Intl.DateTimeFormat(localeCode, {weekday: 'long', year: 'numeric', month: 'long', day: 'numeric', timeZone: 'UTC'}) on toUTCWallClockDate(date) to render the full localized weekday, full month name, day, and 4-digit year (Monday, December 14, 2026).

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

In src/pages/Travel/TrainTripDetails.tsx, format the standalone Rail Date field using DateUtils.formatToLongDateWithWeekday(new Date(reservation.start.date), dateFnsLocale) (matching TripDetailsView.tsx) while keeping startDate.hour and endDate.hour from getFormattedTransportDateAndHour for the Departs and Arrives time fields:

    const startDate = DateUtils.getFormattedTransportDateAndHour(new Date(reservation.start.date), dateFnsLocale);
    const endDate = DateUtils.getFormattedTransportDateAndHour(new Date(reservation.end.date), dateFnsLocale);
    const formattedStartDate = DateUtils.formatToLongDateWithWeekday(new Date(reservation.start.date), dateFnsLocale);

And update the Date MenuItemField in src/pages/Travel/TrainTripDetails.tsx:49-53:

            <MenuItemField
                name={translate('common.date')}
                value={formattedStartDate}
            >
                {!!formattedStartDate && <MenuItem.Copy value={formattedStartDate} />}
            </MenuItemField>

What alternative solutions did you explore? (Optional)

Modifying DateUtils.getFormattedTransportDateAndHour() directly was ruled out because FlightTripDetails and existing unit tests in tests/unit/DateUtilsTest.ts rely on its compact format, and changing it globally would alter flight date formatting across the app.

@zaidrain06

📣 @zaidrain06! 📣
Hey, it seems we don’t have your contributor details yet! You'll only have to do this once, and this is how we'll hire you on Upwork.
Please follow these steps:

Make sure you've read and understood the contributing guidelines.
Get the email address used to login to your Expensify account. If you don't already have an Expensify account, create one here. If you have multiple accounts (e.g. one for testing), please use your main account email.
Get the link to your Upwork profile. It's necessary because we only pay via Upwork. You can access it by logging in, and then clicking on your name. It'll look like this. If you don't already have an account, sign up for one here.
Copy the format below and paste it in a comment on this issue. Replace the placeholder text with your actual details.

Format:

Contributor details
Your Expensify account email: <REPLACE EMAIL HERE>
Upwork Profile Link: <REPLACE LINK HERE>

Contributor details
Your Expensify account email: bydelibozok@gmail.com
Upwork Profile Link: https://www.upwork.com/freelancers/~01c95ae76603189dc9

⚠️ Invalid email. Please make sure to create an Expensify account with this email first here.

Will check the issue today or tomorrow

Proposal

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

In the workspace chat trip room, when opening a booked railroad trip and inspecting the "Rail details" page, the Date field displays as "Monday, Dec 14" (abbreviating the month and omitting the year) instead of the expected full localized format "Monday, December 14, 2026".

What is the root cause of that problem?

In src/pages/Travel/TrainTripDetails.tsx (lines 34–52):

const startDate = DateUtils.getFormattedTransportDateAndHour(new Date(reservation.start.date), dateFnsLocale);
const endDate = DateUtils.getFormattedTransportDateAndHour(new Date(reservation.end.date), dateFnsLocale);
...
<MenuItemField
    name={translate('common.date')}
    value={startDate.date}
/>

startDate.date is generated by DateUtils.getFormattedTransportDateAndHour (src/libs/DateUtils.ts:1013-1027):

if (isThisYear(date)) {
    return {
        date: formatToWeekdayDate(date, dateFnsLocale, false),
        hour: format(date, CONST.DATE.LOCAL_TIME_FORMAT, {locale: dateFnsLocale}),
    };
}

For dates within the current year (isThisYear(date)), formatToWeekdayDate is called with shouldIncludeYear = false, which uses memoizedCreateWeekdayDateFormatter configured with {weekday: 'long', month: 'short', day: 'numeric', year: undefined}. This results in the abbreviated format Monday, Dec 14.
While the compact startDate.hour / endDate.hour format is appropriate for departure/arrival times, the standalone Date field in trip reservations is intended to display the full localized long date with weekday, full month name, day, and 4-digit year (consistent with TripDetailsView.tsx:79, which uses DateUtils.formatToLongDateWithWeekday).
Additionally, TrainTripDetails.tsx is missing <MenuItem.Copy value={...} /> inside the Date <MenuItemField>, unlike FlightTripDetails.tsx:89.

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

In src/pages/Travel/TrainTripDetails.tsx:
Replace startDate.date with DateUtils.formatToLongDateWithWeekday(new Date(reservation.start.date), dateFnsLocale), and add <MenuItem.Copy>:

--- a/src/pages/Travel/TrainTripDetails.tsx
+++ b/src/pages/Travel/TrainTripDetails.tsx
@@ -48,8 +48,10 @@ function TrainTripDetails({reservation, personalDetails}: TrainTripDetailsProps)
             </MenuItemField>
             <MenuItemField
                 name={translate('common.date')}
-                value={startDate.date}
-            />
+                value={DateUtils.formatToLongDateWithWeekday(new Date(reservation.start.date), dateFnsLocale)}
+            >
+                <MenuItem.Copy value={DateUtils.formatToLongDateWithWeekday(new Date(reservation.start.date), dateFnsLocale)} />
+            </MenuItemField>

             <MenuItem.Root>

Keep DateUtils.getFormattedTransportDateAndHour unchanged for startDate.hour and endDate.hour on the travel.trainDetails.departs and travel.trainDetails.arrives rows, preserving localized time formatting.

What alternative solutions did you explore? (Optional)

Modifying DateUtils.getFormattedTransportDateAndHour directly was explored and rejected, because getFormattedTransportDateAndHour is a shared transport utility used by FlightTripDetails.tsx, HotelTripDetails.tsx, and CarTripDetails.tsx (e.g. CarTripDetails.tsx:51, where {pickUpDate.date} • {pickUpDate.hour} is rendered in a compact single-line layout). Changing the shared function would regress existing compact layouts and contradict established unit tests. Using DateUtils.formatToLongDateWithWeekday directly in TrainTripDetails.tsx is completely isolated, safe, and aligns with TripDetailsView.tsx:79.

What automated tests can you add to prevent this from re-occurring?

In tests/unit/DateUtilsTest.ts:
Verify that DateUtils.formatToLongDateWithWeekday always returns weekday, full month name, day, and 4-digit year for both current-year and future-year dates across supported locales (en, es).

Not sure if it's a real bug
This format has existed since #52823, and #105863 didn't touch TrainTripDetails
Flight, Hotel, and Car details use the same format, so it looks intentional. Changing only Rail would make it inconsistent
Or we can update all these places

CC: @Expensify/design

@ZhenjaHorbach

Thanks for checking @ZhenjaHorbach! That makes total sense. Standardizing the date format (and copy action) across all travel components (TrainTripDetails, FlightTripDetails, HotelTripDetails, and CarTripDetails) would provide a much more consistent UX across the whole Travel suite. My proposal easily extends to update all 4 places cleanly without regressions. Happy to implement the unified update across all of them if @Expensify/design gives the green light!

Proposals without Help wanted label are ignored
Please read the guides

I think this format, Monday, Dec 14, is what we want. I'd only expect to see the year if it wasn't the current year, and even then, I'd still expect the shorter month (i.e. Monday, Dec 14, 2027). @Expensify/design for a gut check there though.

That checks out to me 👍

Makes sense to me too 👍

Okay then
Thanks for your thoughts!
Let's close this!

Navigation Menu

Repository navigation

[$175] Rail trip date does not include a year in the trip room/ rail details #106263

Action Performed:

Expected Result:

Actual Result:

Workaround:

Platforms:

Screenshots/Videos

Proposal

What is the root cause of that problem?

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

What alternative solutions did you explore? (Optional)

Proposal for Issue #106263 — Rail trip date does not include a year in the trip room/rail details ($175)

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

Root cause

Fix

Test plan

Proposal

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

What is the root cause of that problem?

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

What alternative solutions did you explore? (Optional)

16 remaining items

Proposal

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

What is the root cause of that problem?

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

What alternative solutions did you explore? (Optional)

What automated tests can you add to prevent this from re-occurring?

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

[$175] Rail trip date does not include a year in the trip room/ rail details #106263

Description

Action Performed:

Expected Result:

Actual Result:

Workaround:

Platforms:

Screenshots/Videos

Activity

applause-bot commented on Nov 6, 2026

melvin-bot commented on Nov 6, 2026

melvin-bot commented on Nov 6, 2026

MelvinBot commented on Nov 6, 2026

Proposal

What is the root cause of that problem?

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

What alternative solutions did you explore? (Optional)

vanshshah11 commented on Nov 6, 2026

Proposal for Issue #106263 — Rail trip date does not include a year in the trip room/rail details ($175)

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

Root cause

Fix

Test plan

zaidrain06 commented on Nov 6, 2026

Proposal

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

What is the root cause of that problem?

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

What alternative solutions did you explore? (Optional)

melvin-bot commented on Nov 6, 2026

zaidrain06 commented on Nov 6, 2026

melvin-bot commented on Nov 6, 2026

16 remaining items

ZhenjaHorbach commented on Nov 10, 2026

jmquero92 commented on Nov 11, 2026

Proposal

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

What is the root cause of that problem?

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

What alternative solutions did you explore? (Optional)

What automated tests can you add to prevent this from re-occurring?

ZhenjaHorbach commented on Nov 11, 2026

jmquero92 commented on Nov 11, 2026

ZhenjaHorbach commented on Nov 11, 2026

dannymcclain commented on Nov 11, 2026

shawnborton commented on Nov 11, 2026

dubielzyk-expensify commented on Nov 11, 2026

ZhenjaHorbach commented on Nov 13, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions