Resolution
If your goal is simply to ensure the same point in time is represented across server and client, trust Nuxt's automatic serialization. When you return a JavaScript Date object from useAsyncData or useState, Nuxt serializes it to an ISO-8601 UTC string via devalue and re-hydrates it as a Date object on the client. This process is independent of the server's local timezone.
However, if you must preserve the original timezone offset (e.g., knowing the date was created in UTC-5 rather than just knowing the UTC instant), you should manually convert the date to a string before returning it. This prevents Nuxt from forcing the value into a UTC-normalized Date object during hydration.
Technical Explanation
Automatic Behavior (The Default)
Nuxt's serialization pipeline converts Date objects to strings formatted as YYYY-MM-DDTHH:mm:ss.sssZ. Because the Z suffix explicitly denotes UTC, the client-side hydration process creates a new Date object that represents that exact UTC moment. The server's local system time does not shift this value because the serialization is normalized to UTC.
Manual Conversion (Offset Preservation)
When you return a string instead of a Date object, Nuxt treats it as a primitive string and performs no further transformation. To guarantee identical values and preserve offsets, use the ISO 8601 format with the offset included (e.g., 2026-10-06T17:35:33-04:00) instead of the Z suffix.
Implementation Steps
- For UTC Consistency: Return the
Date object directly.
const { data } = await useAsyncData('date', () => Promise.resolve(new Date())) - For Offset Preservation: Convert the date to a string containing the offset before returning it from the async function.
- Client-Side Re-parsing: If you used manual conversion, parse the string back into a date object within your component logic using
new Date(data.value).
Verification
To verify the behavior, inspect the HTML source of your rendered page. Look for the __NUXT__ payload block. If you see a date string ending in Z, Nuxt handled the serialization automatically. If you see a custom offset (e.g., -05:00), your manual string conversion was successful.
Diagnostic Detail
Does your application need to display the date in the original source timezone, or is it sufficient to display the UTC instant converted to the user's local browser time?