Question
Which Jamstack strategy ensures accurate local dates without stale caching?
Lax Echo
0 reputation · 26 Aug 2020, 16:40 UTC
47.9K views
Loading…
0 reputation · 26 Aug 2020, 16:40 UTC
To display event dates in the user’s local time on a Jamstack site while keeping the build process simple and ensuring SEO friendliness.
Jamstack sites are pre‑rendered; static pages may hard‑code dates, causing stale or incorrect times when users visit from different time zones. Client‑side conversion via Intl.DateTimeFormat or libraries like date‑fns‑tz exposes raw UTC timestamps and adds runtime overhead. Serverless or edge functions can perform conversion per request, but they must rely on headers such as Accept-Language or custom X‑Timezone, and may be limited by caching layers.
Which approach—build‑time locale‑specific rendering, client‑side conversion, or edge‑function conversion—offers the best balance of accuracy, performance, and SEO for high‑traffic Jamstack sites?
What are the practical trade‑offs in cache invalidation and revalidation when using each method?
Can edge functions reliably detect a user’s timezone from HTTP headers without compromising privacy or performance?
33275 reputation · 26 Aug 2020, 23:04 UTC
For most high-traffic Jamstack sites, the recommended approach is to serve an ISO 8601 timestamp at the edge and format it client-side with Intl.DateTimeFormat. This keeps the build process simple, avoids hard-coded dates in static HTML, and ensures the displayed date reflects the user’s current local timezone.
jamstackAccept-Language or a custom X-Timezone header to apply the correct timezone offset before returning an ISO 8601 string for client formatting.revalidate and Cache-Control: public, max-age=0, must-revalidate can force a fresh fetch on each interaction, preventing stale date displays.new Date(timestamp).toLocaleString() or Intl.DateTimeFormat for local formatting.One missing diagnostic detail that could change the recommendation: whether your SSG and edge runtime honor must-revalidate as expected.
Use comments to ask for clarification. Post a solution as an answer.
33,275 reputation · 26 Aug 2020, 20:59 UTC
While client-side hydration using Intl.DateTimeFormat effectively bypasses cache invalidation issues, it can introduce Cumulative Layout Shift (CLS) if the UTC fallback string differs in length from the localized output.
To maintain visual stability, consider these practical verification steps:
When verifying this in browser developer tools, simulate a slow network connection to observe the hydration gap and ensure the layout remains stable across different locale formats (e.g., US vs. European date structures).