Custom ParameterConverter vs Manual Parsing for ZonedDateTime with IANA Zones in Ktor Routes

Ktor 2.x lacks a built-in ParameterConverter for java.time.ZonedDateTime that understands IANA time zone identifiers such as America/New_York. Two documented approaches exist: register a custom ParameterConverter<ZonedDateTime> via Application.convertForParameters() that parses ISO-8601 strings containing zone offsets or IDs, or accept the time zone as a separate String parameter and combine it with a LocalDateTime inside the handler.

The converter approach centralizes parsing logic and enables type-safe route signatures like get<ZonedDateTime>("dt"), but it introduces a dependency on a current time zone database and requires careful exception handling to avoid 500 responses. Manual parsing keeps dependencies minimal but scatters conversion logic across handlers and loses the declarative parameter binding that Ktor's routing DSL provides.

Which approach better balances maintainability, testability, and runtime reliability for a JVM-only service that must parse request parameters such as 2026-10-19T14:46:09-04:00[America/New_York]? Does the converter strategy justify the added complexity of managing IANA zone data freshness in production deployments?