Express + Luxon: Validating Client-Supplied IANA Timezones at the Middleware Boundary

Integration Goal

An Express API uses a small middleware to read a client-provided x-user-timezone header, resolve it to an IANA zone string, and attach it as req.tz for downstream route handlers. Response serialization relies on Luxon’s DateTime.fromJSDate(date).setZone(req.tz).toISO() to emit timestamps in the user’s local offset.

Constraints and Uncertainty

The middleware currently accepts any header value and passes it directly to Luxon. Invalid or spoofed zone strings (e.g., "Etc/GMT+5" typos, "America/Invalid", or deliberately malformed input) cause setZone to throw at runtime, resulting in 500 responses. Node 18+ exposes Intl.supportedValuesOf('timeZone') for an authoritative IANA list, but the allowlist adds startup overhead and must stay in sync with the runtime’s ICU data. Meanwhile, some clients may omit the header entirely, requiring a safe fallback (typically UTC) without masking genuine configuration errors.

Questions

1. Should the middleware validate against Intl.supportedValuesOf('timeZone') on every request, cache the allowlist at startup, or use a curated static list to avoid ICU drift?
2. When validation fails, is it preferable to fall back silently to UTC, return a 400 with a structured error, or attach a warning header while proceeding with UTC?
3. How should the middleware handle ambiguous or skipped local times during DST transitions when the resolved zone is valid but the target timestamp falls in a gap or overlap?