postgresql 中 timestamp with time zone 字段的显示时区受客户端环境影响，java jdbc 默认使用系统本地时区（如 utc+2），而 ide 数据库工具常默认采用数据库时区（utc），导致同一查询返回不同格式的时间值。
postgresql 中 timestamp with time zone 字段的显示时区受客户端环境影响，java jdbc 默认使用系统本地时区（如 utc+2），而 ide 数据库工具常默认采用数据库时区（utc），导致同一查询返回不同格式的时间值。
在 PostgreSQL 中，TIMESTAMP WITH TIME ZONE（即 timestamptz）类型本质上是以 UTC 存储的绝对时间点，其内部值不随时区变化；但查询结果的字符串表示形式（如 ResultSet.getString("uploaded_at")）取决于客户端时区设置——这正是你观察到差异的根本原因。
- IntelliJ Database Tool 和 pgAdmin 通常将客户端时区设为
UTC（或显式继承数据库timezone参数），因此显示为2023-06-29 19:49:18.103044+00； - 而 Java 应用通过 JDBC 连接时，默认使用 JVM 启动时的
user.timezone（例如系统为 CEST/UTC+2，则显示为+02），故输出2023-06-29 21:49:18.103044+02——注意：这是同一时刻的等效表示，并非数据错误。
✅ 推荐解决方案（安全、可移植、符合最佳实践）：
避免依赖 getString() 解析带时区的时间字符串，改用类型安全的 getTimestamp() 或 getObject() 并显式指定时区：
while (resultSet.next()) {
long id = resultSet.getLong("id");
// 推荐：获取 Instant（JDBC 4.2+），天然 UTC，无歧义
Instant uploadedAt = resultSet.getObject("uploaded_at", Instant.class);
System.out.println(id + " | " + uploadedAt); // 输出：1 | 2023-06-29T19:49:18.103044Z
// 或指定时区解析（如需特定时区的 LocalDateTime）
ZonedDateTime zdt = uploadedAt.atZone(ZoneId.of("UTC"));
System.out.println("UTC: " + zdt); // 2023-06-29T19:49:18.103044Z
}
⚠️ 不推荐的临时修复（仅作兼容性参考）：
如必须保持 getString() 行为一致，可在启动 JVM 时强制统一时区：
java -Duser.timezone=UTC -jar your-app.jar
但该方式影响全局 Date、Calendar 等行为，易引发其他模块时区逻辑混乱，不建议用于生产环境。
? 额外建议：
- 在 PostgreSQL 中检查当前会话时区：
SHOW timezone; - 验证数据库默认时区：
SELECT current_setting('timezone'); - JDBC URL 中也可显式指定时区（优先级高于 JVM 设置）：
jdbc:postgresql://host/db?serverTimezone=UTC&applicationName=myapp
归根结底，时区问题的本质是展示层差异，而非存储层错误。坚持使用 Instant / OffsetDateTime 处理 timestamptz，并避免字符串解析，即可彻底规避此类不一致。
