Why does a web service render timestamps in the server's own time zone, and how is a per-request zone resolved?

## Locale and time zone are different facts A **locale** answers which language and which regional conventions to use. A **time zone** answers what wall-clock time a given instant corresponds to for this reader. They travel separately, and conflating them is the root of most of the bugs in this area. The client's language preference header is a list of languages; it carries no zone. A locale's region subtag identifies a country or territory, not a zone - several countries span multiple zones, and some zones cross national borders - so deriving a zone from the locale is a guess that is wrong for a large minority of users. ## Where the server's own zone comes from When a formatter is asked to render an instant as a wall-clock time and no zone is supplied, it uses the **process default**. That default is not chosen by the application; it comes from the host or container configuration. Two consequences follow: - **Environments disagree.** A container image usually runs with its clock zone set to `UTC`, while a developer machine runs the developer's local zone. Identical code renders identical data differently, and the bug reproduces only in one place. - **The dependency is invisible.** Nothing in the code names a zone, so nothing in review flags it. The behaviour changes when someone changes a base image or a host setting, which makes the eventual incident hard to attribute. | signal | carries a zone | what it is good for | |---|---|---| | language preference header | no | choosing language and regional conventions | | locale region | no - a country can span zones | a weak last-resort guess at best | | stored user preference | yes | the authoritative choice for a signed-in user | | zone measured and sent by the client | yes, for right now | a hint, and a good first-visit default | | process default | yes, but the host's, not the user's | a deterministic fallback if set to `UTC` | ## Resolving a zone per request The zone gets its own resolution chain, shaped like the locale's but fed by different sources: 1. **An explicit stored preference** on the user's profile or in a cookie - the only source that reflects a decision the user made. 2. **A zone the client measured and sent** - the device knows its own zone, and it can be carried as a cookie value or an explicit field. Treat it as a hint: a travelling or borrowed device reports the zone of the moment, not the user's home zone. 3. **A configured default**, ideally `UTC`, so that the fallback is deterministic everywhere rather than a property of the host. Whichever source wins, the result should be validated against a known set of **zone identifiers** and attached to the request next to the locale, so every formatter reads it from one place. ## Convert only at the boundary The discipline that makes all of this tractable is to keep the internal representation zone-free: - **Store and transport instants in `UTC`.** An instant is a point on the timeline and carries no wall-clock ambiguity. - **Convert to a wall-clock rendering at the moment of display**, using the resolved zone - the same boundary where the locale decides the date's textual format. - **Never store a naive local time** as if it were an instant. Without a zone attached, the value cannot be converted back reliably, and the original zone is unrecoverable once it is lost. An alternative that removes the problem entirely for browser clients is to send the instant and let the client render it in its own zone. That is a legitimate design; it just moves the boundary, and it does not help for server-rendered mail, exports, or reports. ## Traps worth naming - **Mutating the process default per request.** It is a single global shared by every request in flight, so one request's zone leaks into another's rendering, non-deterministically and usually under load. - **Trusting the client-sent zone over an explicit preference.** The device is right about where it is and wrong about what the user wants. - **Rendering in the server zone but labelling it with the user's locale.** The output looks localized and states the wrong time, which is worse than an obviously foreign format. - **Forgetting the log and audit path.** Logs almost always want a fixed zone, usually `UTC`, and should not follow the request's resolved zone; correlating incidents across machines depends on that.