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

Answer Overview

Validate the x-user-timezone header once per request using the runtime’s Intl API, fall back to UTC with an explicit warning when the value is invalid or missing, and rely on Luxon’s setZone for serialization—no extra DST handling is needed for fromJSDate.

Confirmed Facts

1. Luxon’s DateTime.setZone does not throw for an unknown zone; it creates an invalid DateTime whose toISO() returns null. The 500 errors you see are therefore from unhandled nulls elsewhere, not from Luxon itself.
2. Intl.supportedValuesOf('timeZone') (Node 18+) returns an implementation‑specific subset that omits some valid aliases (e.g., US/Eastern). Using it as a strict allowlist can reject legitimate zones.
3. Creating a temporary Intl.DateTimeFormat with the candidate zone and checking resolvedOptions().timeZone validates the zone against the exact ICU data Luxon will use, with zero drift risk.
4. For an existing instant (JS Date), converting to a zone via setZone never encounters DST gaps or overlaps; those only matter when constructing local wall‑clock times.

Recommended Middleware Steps

1. Sanitize input: trim the header, reject empty strings, limit length (e.g., 64 chars) and strip control characters.
2. Validate zone:
1. Try new Intl.DateTimeFormat(undefined, { timeZone: value }).
2. Call fmt.resolvedOptions().timeZone; if it returns a string, the zone is valid.
3. If any step throws or returns a different string, treat the zone as invalid.
3. Cache the validation function (no need to cache a list; the Intl call is cheap). If you prefer an allowlist, generate Intl.supportedValuesOf('timeZone') once at startup and store it in a Set; otherwise skip the list entirely.
4. Attach or fallback:
1. If valid: req.tz = value.
2. If invalid or missing: req.tz = 'UTC' and set a response header x-timezone-fallback: utc (or include a warning field in JSON).
5. Logging: log invalid values at warn level (sanitized, length‑capped); do not log the missing‑header case.

Why This Works

The validation uses the same ICU data that Luxon consults, guaranteeing that any zone accepted by the middleware will be accepted by setZone. Falling back to UTC with an explicit header informs clients that their input was ignored without causing a 500, and it preserves the ability to treat the timezone as semantically required on write‑intensive endpoints (where you would return 400 instead).

Verification Steps

1. Unit test: send x-user-timezone: America/Invalid; assert req.tz === 'UTC' and that the response contains x-timezone-fallback: utc.
2. Unit test: send x-user-timezone: America/New_York; assert req.tz === 'America/New_York' and no fallback header.
3. Integration test: POST a known UTC instant, verify the serialized offset matches the requested zone (e.g., -04:00 for America/New_York in October).
4. Confirm the Node image has full ICU by checking that Intl.DateTimeFormat('en', {timeZone:'America/Santiago'}) does not throw.

Missing Diagnostic Detail

If your API treats the timezone as a required parameter for mutating operations (e.g., scheduling), you may want to return a 400 instead of falling back. Let me know whether the endpoint is read‑only or write‑heavy so I can adjust the failure policy.