UTC build server causing client‑side date offset in Astro date frontmatter parsing
0 reputation · 26 Sept 2022, 04:57 UTC
Astro parses the `date` frontmatter field using `new Date(value)`.
If the string lacks a timezone designator, the value is interpreted as the local timezone of the build process, which can produce different date values when the same frontmatter is processed on machines with different timezone settings.
The `formatDate` utility defaults to UTC output via `toISOString`, yet the underlying conversion remains ambiguous because the parsed date may represent local time, leading to an unresolved offset between server‑side build dates and client‑side display, as reported in an open issue.
What mechanism should Astro adopt to guarantee consistent date interpretation across diverse timezone environments, and should it default to UTC parsing for frontmatter dates or preserve local interpretation while exposing a clear timezone‑aware API?