The data-access layer now supports time-zone-aware temporal types across the engines that provide them. Columns declared as TIMESTAMP WITH TIME ZONE and TIME WITH TIME ZONE are read with their offset preserved, written from offset-aware values, and reported through the standard JDBC type codes so callers handle them consistently. The data binder also accepts modern Java date and time values directly.
What changed
- Offset-aware read and write. Columns carrying a time-zone offset render from the driver's offset-aware representation on read and bind from offset-aware values on write, so the zone information survives the round trip.
- java.time binding. The data binder accepts LocalDate, LocalTime and LocalDateTime values directly, removing the conversion step previously needed to store modern Java temporal types.
- Standard type reporting. Offset-aware columns report the standard JDBC type code for time-with-time-zone data, so generic tooling and the platform's own metadata layer classify them correctly.
These additions matter for applications that span time zones — scheduling, logistics, multi-region operations — where a timestamp without its offset is ambiguous. The behaviour is consistent across the engines that support the types, with engine-specific mapping handled beneath the common interface.