Expo Router development server vs production native builds: date object time‑zone preservation in route params

Direct answer

No. Expo Router does not preserve a Date object's local time-zone context in route parameters, and there is no Expo Router or SDK option to enforce a specific zone during serialization. Development and production native builds behave the same way.

What actually happens

Route params are strings. When a Date is passed, it is converted to a string—commonly a UTC ISO representation such as 2026-10-15T18:41:40.488Z. A JavaScript Date stores a UTC instant, not a time zone; the local offset is environmental. The receiving screen parses that string into a new Date using its own local zone, so the original display offset is lost.

Confirmed vs. likely

Confirmed: passing raw Date objects through route params is not officially supported; only JSON-serializable primitives are guaranteed to survive intact. Both the Metro dev server and production bundles use the same string-based param mechanism.

Likely: any discrepancy you observed between environments comes from differing local time zones on the host machine versus the simulator or device, not from Expo Router treating the values differently.

Recommended handling

1. Convert explicitly before navigating: use date.toISOString() for a UTC instant, or date.getTime() for epoch milliseconds.
2. Parse it back on the receiving screen with new Date(param).
3. If the original local zone matters, pass an IANA zone name separately (for example, America/New_York) and format with Intl.DateTimeFormat or a dedicated time-zone library.

Verification

To confirm on your setup, log the received param and its offset in both environments:

const { when } = useLocalSearchParams<{ when?: string }>();
console.log(when, new Date(when).getTimezoneOffset());

Compare that offset to the sending screen's getTimezoneOffset(). They will match only when both devices share the same local zone.