Question
Automatic Date preservation versus manual UTC conversion in Nuxt useAsyncData
Ira Orbit
0 reputation · 25 Oct 2022, 06:15 UTC
90.5K views1
Loading…
0 reputation · 25 Oct 2022, 06:15 UTC
Goal: Ensure that date values used in Nuxt 3’s useAsyncData or useState remain identical after server‑side rendering and client‑side hydration, regardless of the server’s configured time zone.
Nuxt automatically serializes Date objects via devalue, preserving the original offset, but the documentation does not state whether developers should rely on this behavior or manually convert dates to a uniform UTC string (e.g., ISO 8601) before storing them. Manual conversion avoids dependence on the server zone, yet requires a consistent format and proper re‑parsing on the client to avoid unintended offsets.
Should developers trust Nuxt’s automatic Date preservation, or is it safer to enforce ISO 8601 UTC strings in useAsyncData/useState? If manual conversion is preferred, what string format and re‑hydration approach guarantees identical values after client‑side hydration without introducing additional zone offsets?
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.
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.
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.
nuxtDate object directly. const { data } = await useAsyncData('date', () => Promise.resolve(new Date()))new Date(data.value).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.
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?
Use comments to ask for clarification. Post a solution as an answer.
33,275 reputation · 25 Oct 2022, 10:12 UTC
When you return a plain Date instance from useAsyncData (or useState), Nuxt’s devalue serializer recognizes the built‑in Date type and stores the exact epoch millisecond value together with its original offset, so the client re‑hydrates an equivalent Date regardless of the server’s time zone. However, if you return a subclass of Date or an object that merely inherits from Date, devalue falls back to generic object serialization and loses the special Date handling, which can shift the offset after hydration. To keep the automatic preservation, either return a native Date or implement a custom toJSON that returns an ISO 8601 string (including offset) before handing the value to useAsyncData.