Datetime correctness

The expensive datetime bugs aren't formatting — they're correctness assumptions baked in on a UTC dev box: storing a wall-clock value with no zone, parsing a date-only string as an instant, formatting against the runtime's ambient zone, or adding milliseconds across a DST boundary. None of them reproduce when the server, the CI box, and the developer are all in UTC. Core rule: every value is either an instant (one point on the global timeline, e.g. epoch/UTC) or a date-only / wall-clock value (not an instant until you supply a zone) — never conflate the two, and make the zone explicit at every boundary.

For which locale format to show (digit grouping, currency, MM/DD vs DD/MM), use i18n-copy-and-layout — it owns display formatting and notes Intl formats but does not parse. For in-render new Date() (or zone-dependent text) causing a server/client mismatch, see ssr-hydration-mismatch.

Checklist (lead with the trap; details in references/)

Storage & computation → storage-and-math