It turns out this is not a bug. This behavior is not particular to ZonedDateTime; java.sql.Timestamp properties have the same issue.

What is happening is similar to what is described by http://stackoverflow.com/questions/22527872/gregoriancalendar-dst-problems#22613210 .

ZonedDateTime values are converted to/from Timstamp for binding and retrieving from the database.

Assuming that hibernate.jdbc.time_zone (introduced in 5.2) is not set, a Timestamp will be bound using:

PreparedStatement#setTimestamp(int parameterIndex, Timestamp x)

Oracle JDBC uses a Calendar for the JVM time zone to convert the Timestamp to the default time zone to persist in the database. In the process of setting fields in the Calendar, Calendar.DST_OFFSET field is cleared. After that happens, the Calendar assumes the time is Standard Time (not Daylight Savings Time), and we see results like the attached test case.

When I debugged using H2, it appears that the DST time may be persisted properly, but the same problem occurs when reading the value from the ResultSet.

The workaround is to set hibernate.jdbc.time_zone=UTC to persist the Timestamp for UTC. That way Hibernate will explicitly provide a Calendar for UTC (which does not have DST, and requires no convertion) for persisting the timestamp.

NOTE: setting hibernate.jdbc.time_zone=UTC will persist all timestamps (not just from ZonedDateTime) using UTC, so pre-existing timestamps should be converted to UTC as well.