PostgreSQL JDBC驱动在DST边界转换LocalDateTime时为何受JVM时区影响？

结论：这是驱动的设计行为，并非bug #

核心原因 #

PostgreSQL的timestamp类型（无时区）本身存储的是壁钟时间，但JDBC驱动处理LocalDateTime参数时，内部会执行一套时区转换逻辑：

1. 把LocalDateTime转成JVM默认时区的ZonedDateTime
2. 将ZonedDateTime转换为UTC时间
3. 再把UTC时间转回数据库的timestamp（默认使用JVM时区）

当JVM时区处于夏令时切换边界时，比如美国东部时区2023年3月12日的2:00，这个时间在夏令时切换中是无效时间（时钟直接从1:59跳至3:00），JDK的时区处理机制会自动将这个无效时间调整为下一个有效时间（3:00）。驱动的转换流程就会把这个调整后的时间传入数据库，最终导致返回结果偏移1小时。

而用ts.toString()传递参数时，驱动直接按文本解析为数据库的timestamp，跳过了整套时区转换步骤，因此能保留原始的壁钟时间，结果符合预期。

对应实验的解释 #

• 切换到夏威夷时区（无夏令时）后，2023-03-12T02:00是有效时间，没有触发JDK的时区调整逻辑，所以驱动传递后结果一致。
• 字符串参数绕开了时区转换，因此不受JVM时区变化的影响。

解决办法 #

如果需要严格传递LocalDateTime的壁钟时间，避免夏令时调整带来的偏移，可以采用以下方式：

• 直接传递LocalDateTime的字符串形式（如ts.toString()）
• 在JDBC URL中显式指定固定时区，例如?serverTimezone=UTC，确保转换过程中不会触发夏令时调整
• 业务允许的话，改用PostgreSQL的timestamptz（带时区）类型存储，但该类型会保留时区信息，需根据场景选择

内容的提问来源于stack exchange，提问作者Chad Showalter