Server‑side date serialization vs client‑side timezone conversion in Next.js

Integration boundary: Server‑side date handling and client‑side timezone conversion in Next.js

The goal is to present dates correctly for users whose preferred time zone is only known at runtime (e.g., from a profile or browser API) while keeping the UI consistent between server‑rendered HTML and the subsequent client hydration.

Constraints: getStaticProps runs at build time and cannot adapt to per‑user zones; getServerSideProps executes on the server where the default time zone may differ from the user’s; performing conversion on the client can cause a flash of UTC‑based content before the client applies Intl.DateTimeFormat with the correct zone.

• Should dates be kept as UTC ISO strings in server‑side props and converted exclusively on the client using the user’s zone?
• Is it viable to derive the user’s time zone from the request (e.g., via headers or cookies) and apply full conversion inside getServerSideProps?
• How can an initial render be made to avoid showing UTC times when the client later re‑formats the date?