Next.js i18n: Where to Convert Dates for User Time Zones

Answer First

Convert timestamps on the server whenever the client supplies a time‑zone (via header, query or cookie). If no zone is provided, fall back to UTC and let the client re‑format locally when needed.

Why this works

• Server conversion keeps a single source of truth and guarantees consistent dates for all users.
• Passing the zone from the client is cheap (one header or cookie) and works with Next.js server components and API routes.
• Client‑side re‑formatting is still possible for quick UI updates when the user changes zones during a session.

Common Pitfalls

• Assuming the user’s OS clock is correct – always validate the zone string.
• Ignoring DST changes – use a library that tracks IANA zones (e.g., date‑fns‑tz or Luxon).
• Over‑refetching on every navigation – cache formatted strings on the client and invalidate only on zone change or UTC update.

Implementation Steps for Your Project

1. Detect the zone on the client:

   const tz = Intl.DateTimeFormat().resolvedOptions().timeZone;
   

   Store tz in a context or Zustand store.
2. Send the zone to the server:
   • For API routes: add a middleware that reads X‑Time‑Zone header or ?tz=… query.
   • For getServerSideProps or server components: read the same header/query.
3. Convert on the server:

   import { utcToZonedTime, format } from 'date-fns-tz';
   const zoned = utcToZonedTime(utcDate, tz);
   const formatted = format(zoned, 'yyyy‑MM‑dd HH:mm', { timeZone: tz });
   

4. Cache on the client:
   • Store the formatted string in a context or local state.
   • Invalidate when tz changes or when the underlying UTC value updates.
5. Handle zone changes during a session:
   • Listen for Intl.DateTimeFormat().resolvedOptions().timeZone changes (e.g., via window.matchMedia or user action).
   • On change, update the context and trigger a re‑render or refetch if you prefer server confirmation.

What We Still Need to Know

To fine‑tune the recommendation, could you confirm how you plan to persist the user’s time‑zone across sessions? (e.g., cookie, localStorage, or a server‑side setting in a database). This will affect whether you lean more heavily on server‑side conversion or client‑side caching.