[Due for payment 2026-07-08] [$250] Cancellation policy date in NewDot is different from the cancellation policy in Spotnana

[nlemma]

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: 9.3.52-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: https://github.com/Expensify/Expensify/issues/505793
Email or phone of affected tester (no customers): applausetester+rg_travel20@applause.expensifail.com
Issue reported by: Applause Internal Team
Bug source: Regression TC Execution
Device used: Windows Windows 11

Action Performed:

1. Book a hotel that has a free cancellation policy
2. Go to the details in Expensify
3. Look at the cancellation policy and compare it to Spotnana

Expected Result:

Cancellation policy date in NewDot should be the same as the cancellation policy in Spotnana

Actual Result:

Cancellation policy date in NewDot is different from the cancellation policy in Spotnana

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7105938_1773812822457.E-60835_-_Cancellation_policy_date_in_NewDot_is_different_from_the_cancellation_policy_in_Spotnana.mp4

View all open jobs on GitHub

Issue Owner

Current Issue Owner: @mallenexpensify

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022040036443421264568
• Upwork Job ID: 2040036443421264568
• Last Price Increase: 2026-04-10

[MelvinBot]

Proposal

What is the root cause of that problem?

The cancellation deadline from Spotnana is a hotel-local-time ISO 8601 string (deadline.iso8601). When the App parses it with new Date() at HotelTripDetails.tsx:36, JavaScript interprets and converts it based on the user's device timezone. The formatted output (via DateUtils.getFormattedCancellationDate at DateUtils.ts:813-818) then displays in the device's local timezone, not the hotel's timezone. If these timezones differ, the displayed date/time shifts — potentially crossing a day boundary.

Spotnana provides a deadlineUtc field (TripData.ts:1219-1222) but it is never used — only the deadline (local) field is read at TripReservationUtils.ts:276.

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

The cancellation deadline should be displayed as the hotel-local date/time (matching what Spotnana shows), without converting to the user's device timezone. Two approaches:

1. Parse deadline.iso8601 as a timezone-naive value — strip any timezone indicator before formatting so format() renders the raw date/time values as-is (hotel-local), rather than converting to the device timezone. This can be done by using parseISO from date-fns (which creates a Date in local time from the string components) or by manually extracting the date/time parts.

2. Alternatively, use deadlineUtc.iso8601 together with the hotel's timezone (available from Spotnana data) to convert UTC → hotel-local time using formatInTimeZone from date-fns-tz. This is more robust but requires passing the hotel timezone through the reservation data.

The simpler fix (option 1) should be applied in TripReservationUtils.ts and/or HotelTripDetails.tsx. The same pattern applies to CarTripDetails.tsx:29 which has the identical issue for car rental cancellation deadlines.

What alternative solutions did you explore? (Optional)

• Switching entirely to deadlineUtc without timezone conversion would show the UTC time, which is also wrong — users expect to see the hotel-local cancellation deadline.
• Adding a timezone label (e.g., "EST") to the displayed time would help but doesn't fix the core date mismatch.

---

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.

[melvin-bot]

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

[melvin-bot]

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

[KJ21-ENG]

Proposal

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

Cancellation policy time shown in NewDot for hotel bookings does not match Spotnana. In the provided video, Spotnana shows cancellation before 19 Apr 2026, 15:00, while NewDot shows Saturday, Apr 18 11:59 PM for the same reservation.

What is the root cause of that problem?

The app stores and displays hotel cancellation deadline using deadline.iso8601 as a plain Date, which is then formatted in the device/browser local timezone. That timezone conversion shifts the displayed local date/time away from the hotel-local deadline shown by Spotnana.

Hotel reservation mapping currently takes cancellationDeadline from deadline.iso8601:

App/src/libs/TripReservationUtils.ts

Lines 271 to 273 in 1d43910

	cancellationPolicy: pnrData.room.cancellationPolicy?.policy ?? null,
	cancellationDeadline: pnrData.room.cancellationPolicy?.deadline?.iso8601 ?? null,
	confirmations,

Hotel details render path converts this string with new Date(...) and formats it:

App/src/pages/Travel/HotelTripDetails.tsx

Lines 35 to 37 in 1d43910

	const cancellationText = reservation.cancellationDeadline
	? `${translate('travel.hotelDetails.cancellationUntil')} ${DateUtils.getFormattedCancellationDate(new Date(reservation.cancellationDeadline))}`
	: cancellationMapping[reservation.cancellationPolicy ?? CONST.CANCELLATION_POLICY.UNKNOWN];

App/src/libs/DateUtils.ts

Lines 813 to 818 in 1d43910

	function getFormattedCancellationDate(date: Date): string {
	if (isThisYear(date)) {
	return format(date, 'EEEE, MMM d h:mm a');
	}
	return format(date, 'EEEE, MMM d, yyyy h:mm a');
	}

Spotnana payload also provides deadlineUtc, but it is not used in reservation mapping/display logic:

App/src/types/onyx/TripData.ts

Lines 1216 to 1220 in 1d43910

	/** Deadline in UTC for the cancellation. */
	deadlineUtc: {
	/** ISO 8601 format. */
	iso8601: string;
	};

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

1. Stop treating hotel cancellation deadline as device-local display time. Use a canonical source that can be converted to the correct business timezone (hotel/local policy timezone) before rendering.
2. In reservation mapping/rendering, prefer a deterministic conversion path (e.g., deadlineUtc + explicit target timezone) instead of direct new Date(deadline.iso8601) for UI text.
3. Keep current fallback policy text behavior unchanged when no deadline exists.
4. Add regression coverage for a reservation where hotel timezone differs from tester/device timezone, verifying NewDot cancellation date/time matches Spotnana policy text.

What alternative solutions did you explore? (Optional)

• Parsing deadline.iso8601 as a naive local string can reduce some shifts but is brittle if source timezone semantics vary across suppliers.
• A UTC-based canonical conversion with explicit display timezone is safer and more consistent across hotel/car travel details.

[trasnake87]

Proposal

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

The cancellation deadline displayed for hotel bookings in NewDot does not match what Spotnana shows, because the date/time is shifted by the user's device timezone offset instead of being shown in the venue's local time.

What is the root cause of that problem?

The Reservation type in Transaction.ts#L306 stores cancellationDeadline as a plain string but carries no venue timezone metadata. When CarTripDetails.tsx (which has the same bug at CarTripDetails.tsx#L29) and the hotel details component consume this value, they call new Date(reservation.cancellationDeadline) which converts the ISO 8601 string (containing the venue's UTC offset, e.g. 2025-04-02T19:00:00-05:00) into a UTC-internal Date. Then date-fns's format() renders it in the device's local timezone rather than the venue's. The offset embedded in the original ISO string is the key to displaying the correct venue-local time, but it is lost once new Date() absorbs it.

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

We should extract the UTC offset from the ISO 8601 cancellationDeadline string and use formatInTimeZone (already available in the codebase via date-fns-tz) to render the date in the venue's original timezone. This fix goes in CarTripDetails.tsx (and the equivalent hotel component) without modifying shared utility functions:

// CarTripDetails.tsx – replace line 29
import {formatInTimeZone} from 'date-fns-tz';
import {isThisYear} from 'date-fns';

if (reservation.cancellationDeadline) {
    const offsetMatch = reservation.cancellationDeadline.match(/([+-]\d{2}:\d{2})$/);
    const venueTimeZone = offsetMatch ? `GMT${offsetMatch[1]}` : 'UTC';
    const deadlineDate = new Date(reservation.cancellationDeadline);
    const pattern = isThisYear(deadlineDate) ? 'EEEE, MMM d h:mm a' : 'EEEE, MMM d, yyyy h:mm a';
    cancellationText = `${translate('travel.carDetails.cancellationUntil')} ${formatInTimeZone(deadlineDate, venueTimeZone, pattern)}`;
}

This preserves the venue-local date/time by formatting back into the original offset timezone rather than the user's device timezone. The same pattern should be applied in the hotel details component. This approach is a localized, component-level fix that requires no changes to shared types or utilities.

[trasnake87]

Contributor details
Your Expensify account email: trasnake87@gmail.com
Upwork Profile Link: https://www.upwork.com/freelancers/~010f770315ab181656

[melvin-bot]

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

[wildan-m]

Proposal

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

The cancellation policy date shown in NewDot for hotel (and car) bookings does not match the date shown by Spotnana. The displayed date/time shifts because the app converts it to the user's device timezone instead of displaying the booking-local time.

What is the root cause of that problem?

The Spotnana deadline.iso8601 field contains the cancellation deadline in the booking-local timezone (e.g. 2026-04-19T15:00:00+07:00 for a hotel in Bangkok). When HotelTripDetails passes this string through new Date(reservation.cancellationDeadline), JavaScript converts it to UTC internally. Then DateUtils.getFormattedCancellationDate calls format() from date-fns which renders the Date in the device's local timezone — shifting the displayed date/time away from the booking-local value that Spotnana shows.

The conversion happens here in HotelTripDetails:

App/src/pages/Travel/HotelTripDetails.tsx

Lines 35 to 37 in 0eda3f5

	const cancellationText = reservation.cancellationDeadline
	? `${translate('travel.hotelDetails.cancellationUntil')} ${DateUtils.getFormattedCancellationDate(new Date(reservation.cancellationDeadline))}`
	: cancellationMapping[reservation.cancellationPolicy ?? CONST.CANCELLATION_POLICY.UNKNOWN];

And identically in CarTripDetails:

App/src/pages/Travel/CarTripDetails.tsx

Lines 28 to 29 in 0eda3f5

	if (reservation.cancellationDeadline) {
	cancellationText = `${translate('travel.carDetails.cancellationUntil')} ${DateUtils.getFormattedCancellationDate(new Date(reservation.cancellationDeadline))}`;

Both call DateUtils.getFormattedCancellationDate which formats in device-local time:

App/src/libs/DateUtils.ts

Lines 813 to 818 in 0eda3f5

	function getFormattedCancellationDate(date: Date): string {
	if (isThisYear(date)) {
	return format(date, 'EEEE, MMM d h:mm a');
	}
	return format(date, 'EEEE, MMM d, yyyy h:mm a');
	}

The reservation mapping reads deadline.iso8601 for hotels:

App/src/libs/TripReservationUtils.ts

Line 276 in 0eda3f5

cancellationDeadline: pnrData.room.cancellationPolicy?.deadline?.iso8601 ?? null,

And for cars:

App/src/libs/TripReservationUtils.ts

Line 326 in 0eda3f5

cancellationDeadline: pnrData.cancellationPolicy?.deadline.iso8601 ?? null,

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

Change getFormattedCancellationDate in DateUtils.ts to accept the raw ISO 8601 string instead of a Date, and strip any timezone offset suffix (e.g. +07:00, -04:00, Z) before parsing. This preserves the original date/time components from deadline.iso8601 as-is, which represent the booking-local cancellation deadline — exactly what Spotnana displays.

Specifically:

1. In getFormattedCancellationDate, strip the timezone suffix from the input string with a regex before creating the Date, so the datetime components are treated as naive local values and format() outputs them unchanged.
2. Update the two callers (HotelTripDetails.tsx and CarTripDetails.tsx) to pass the string directly instead of wrapping in new Date().

This approach works uniformly for both hotel and car cancellation deadlines — the deadline.iso8601 field in both HotelPnr and CarPnr represents the booking-local time.

Compare branch: https://github.com/Expensify/App/compare/main...wildan-m:App:wildan/87076-cancellation-date-timezone?expand=1

What alternative solutions did you explore? (Optional)

Using deadlineUtc.iso8601 combined with the venue's timezone (available at hotelInfo.address.timezone) and formatInTimeZone from date-fns-tz to convert UTC to venue-local time. While more explicit, this approach has a practical limitation: CarPnr does not have a deadlineUtc field (only deadline), so it cannot be applied uniformly to both hotel and car cancellation deadlines without divergent logic. The timezone-stripping approach handles both consistently with a single code path.