Regional time-zone date conversion across Svelte 5 runes and SvelteKit 2 SSR boundary

Resolution

To ensure consistent date rendering across the SvelteKit 2 SSR boundary and Svelte 5 runes, pass UTC ISO strings from the server and apply the IANA time zone explicitly during the rendering phase using a $derived rune.

Do not attempt to serialize a Date object with a specific time zone, as SvelteKit's serialization process converts all Date instances to ISO strings, stripping any local zone metadata. Instead, treat the time zone identifier (e.g., 'America/New_York') as a separate piece of state.

Implementation Pattern

1. Server: Send the date as an ISO string and the target IANA zone as a string via load functions.
2. State: Store these in Svelte 5 runes. Use $state for the zone if it is user-configurable.
3. Derivation: Use a $derived rune to handle the conversion. This ensures that if the date or the zone changes, the formatted string updates automatically without mutating the original date object.

<script>
  let { data } = $props();

  // Store the zone as state to allow reactivity
  let timezone = $state(data.userTimezone);
  let dateString = $state(data.utcDate); // ISO string from server

  // Derived rune prevents hydration mismatch by using a consistent zone
  const formattedDate = $derived(
    new Intl.DateTimeFormat('en-US', {
      timeZone: timezone,
      dateStyle: 'full',
      timeStyle: 'long'
    }).format(new Date(dateString))
  );
</script>

<p>{formattedDate}</p>

Technical Explanation

Hydration Mismatches: These occur when Intl.DateTimeFormat defaults to the system time zone. If the server is in UTC and the client is in PST, the initial HTML will differ from the client's first render. By explicitly passing the timeZone option, you force both environments to produce the same output string.

Svelte 5 Reactivity: Because Date objects are mutable, updating a property inside a Date instance will not trigger a rune update. By using a $derived rune based on an ISO string or a new Date instance, you ensure the UI stays in sync.

Verification Steps

• SSR Check: View the page source (Ctrl+U). The date should be formatted in the target IANA zone, not the server's local time.
• Hydration Check: Ensure no "Hydration failed" warnings appear in the browser console.
• Zone Shift: If using a timezone picker, verify that changing the timezone state immediately updates the formattedDate without a page refresh.

Diagnostic Detail Needed: Are you utilizing a specific library like Luxon or date-fns-tz, or relying solely on the native Intl API? (Library-specific serialization may require different handling of the DateTime object).