Date Header Feature: Regional Time Zones Not Represented

Short answer

Not through the built-in Date feature. Ktor's Date header path funnels through HttpDate, which normalizes the supplied temporal to UTC and formats it with the RFC 1123 GMT pattern. There is no configuration option to keep a regional offset. You can install a custom plugin that writes a zone-preserving string into Date, but that header is then non-compliant and unsafe for caching. The practical resolution is to leave Date in GMT and expose local time in a separate header.

Confirmed facts vs. things to verify

Confirmed by the HTTP specifications: the HTTP-date format used by Date, Expires, Last-Modified and the conditional-request headers is defined with a literal GMT zone token. A numeric offset such as +0200 is not a valid HTTP-date, even though it is a valid RFC 1123 date in other contexts.

Version-dependent and worth checking in your own tree: that the Date feature delegates to HttpDate and converts to UTC before formatting. Read the source or decompiled class for the exact Ktor version you run rather than assuming the behavior is documented as a contract. The same applies to which plugin (default headers, date feature, or both) actually writes the header in your setup.

Why a regional Date header causes real damage

• Caches and intermediaries compare Date, Expires and Last-Modified as instants. A string they cannot parse reliably can be dropped, treated as absent, or mis-ordered.
• Conditional requests assume GMT. A local-time Date can shift the apparent freshness window and produce wrong 200 or 304 outcomes, which shows up as stale or over-fetched responses.
• Strict clients and proxies may reject the response or log protocol errors, and the failure is intermittent because it depends on the offset and the time of day.

What to do instead

1. Keep the existing Date feature installed so Date stays GMT.
2. Add a distinct response header for local time, for example X-Local-Date, and document its format for consumers.
3. Format it with an explicit zone and an offset-bearing pattern so the value is unambiguous.

Illustrative formatting only; the plugin wiring differs between Ktor versions:

val local = ZonedDateTime.now(ZoneId.of("America/New_York"))
    .format(DateTimeFormatter.ISO_OFFSET_DATE_TIME)
// attach it to the response, e.g.:
// call.response.headers.append("X-Local-Date", local)

Verification

curl -sI http://localhost:8080/ | grep -iE '^(date|x-local-date):'

Check that Date still ends in GMT and that the local header carries the offset you expect. If you want to confirm the UTC normalization claim, exercise the formatter directly with a non-UTC ZonedDateTime and inspect the output string.

The one detail that changes the recommendation

Who consumes the value? If the only reader is a client you control, no shared cache or CDN sits in front, and you never issue conditional requests, a non-GMT Date is merely non-standard rather than actively harmful. If any proxy, CDN or browser cache is in the path, keep Date in GMT and use the separate header.