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

Direct answer

For a JVM-only service that can keep its JDK current, a custom ParameterConverter<ZonedDateTime> registered via Application.convertForParameters() better balances maintainability, testability, and runtime reliability. It centralizes parsing logic, enables declarative route signatures like get<ZonedDateTime>("dt"), and reduces duplicated validation across handlers. The added complexity of managing IANA zone data freshness is justified when regular JDK updates keep the runtime's time-zone database current. If zone data freshness cannot be guaranteed or bracketed zone IDs like [America/New_York] are mandatory without JDK updates, manual parsing with a separate String zone parameter and explicit ZoneId validation is safer.

Likely explanation

The converter approach consolidates parsing into a single, testable unit and preserves Ktor's parameter binding semantics. Its cost is coupling to the JRE's time-zone database and the need to map ParameterConversionException to 400 Bad Request rather than letting it produce a 500.

• Ktor 2.x provides no built-in ParameterConverter for ZonedDateTime that understands IANA zone identifiers such as America/New_York. A custom converter registered with convertForParameters(ZonedDateTime::class.java) { converter } must use a DateTimeFormatter matching the expected input format and throw ParameterConversionException on failure so Ktor returns 400 instead of 500. The java.time.ZoneId data originates from the Java runtime's time-zone database; keeping the JDK up-to-date supplies the latest IANA updates. Manual parsing accepts a LocalDateTime and a separate String zone parameter, then combines them with ZonedDateTime.of(localDateTime, ZoneId.of(zone)) inside the handler, with no central registration.

1. Decide on the accepted parameter format (bracketed zone ID, offset-only ISO-8601, or separate dt/zone parameters).
2. If using a custom converter: register it at application start-up with convertForParameters(ZonedDateTime::class.java) { value, _ -> try { ZonedDateTime.parse(value, formatter) } catch (e: DateTimeParseException) { throw ParameterConversionException("Invalid ZonedDateTime: $value") } }. Configure a DateTimeFormatter that matches your request parameter format.
3. Add global error handling to map ParameterConversionException to a 400 Bad Request response, preventing unhandled exceptions from producing 500s.
4. Verify the setup by sending a request with a valid parameter string (e.g., 2026-10-19T14:46:09-04:00[America/New_York]) and asserting that the handler receives a ZonedDateTime with the correct instant, offset, and zone.
5. If opting for manual parsing: accept dt and zone as separate route parameters, validate ZoneId.of(zone) before calling ZonedDateTime.of, and handle DateTimeException as a client error.

One missing diagnostic detail that changes the recommendation: what is your JDK update cadence, and do you require support for bracketed zone IDs like [America/New_York] in addition to offset-only ISO-8601? If updates are infrequent or the bracketed form is mandatory, manual parsing with explicit validation is safer.