java jdbc时区问题核心是统一jvm、驱动、数据库三者时区，需显式配置连接参数（如mysql设servertimezone=asia/shanghai）、禁用旧时间api、使用java.time、校准服务端与jvm时区，并通过sql和java日志验证一致性。
Java 中 JDBC 处理数据库时区不一致问题，核心是让 JVM、JDBC 驱动、数据库三者对时间的理解保持一致。偏差常表现为插入时间比预期早/晚若干小时（如 8 小时或 14 小时），本质是时间戳被错误解释为不同基准时区。
统一 JDBC 连接参数中的时区
这是最直接有效的入口级控制，必须在连接 URL 中显式声明时区，不能依赖默认值。
- MySQL：添加 serverTimezone=Asia/Shanghai（推荐）或 serverTimezone=GMT%2B8（URL 编码后为
%2B），避免使用模糊值如CST（可能被解析为美国中部时间 UTC-6） - TDengine：使用 timezone=Asia/Shanghai，注意必须是 IANA 标准 ID（如
Asia/Shanghai），不支持GMT+8或+08:00 - Oracle：若报 ORA-01882，优先检查 JDBC URL 是否含 oracle.jdbc.timezoneAsRegion=true，并确保系统已加载对应时区数据
规范 Java 应用层的时间类型与操作
即使连接参数正确，代码中误用旧 API 仍会引入偏差。
- 禁用
new Date()和SimpleDateFormat，它们隐式依赖TimeZone.getDefault() - 统一使用
java.time包：插入时用ZonedDateTime.now(ZoneId.of("Asia/Shanghai"))或Instant.now()（存 UTC）；查询后按需转换显示 - 若用 MyBatis 或 JPA，确认其时间字段映射是否启用时区感知（如 MyBatis 的
@Options(useGeneratedKeys = true)不影响时区，但类型处理器需适配）
校准 JVM 与数据库服务端时区
连接参数只是客户端行为，服务端配置同样关键，否则可能造成读写逻辑错位。
- JVM 启动时加参数：-Duser.timezone=Asia/Shanghai，确保所有基于
TimeZone.getDefault()的逻辑（如日志时间、定时任务）一致 - MySQL 服务端设置：执行
SET GLOBAL time_zone = '+08:00';或在my.cnf的[mysqld]下加default-time-zone='+08:00' - TDengine 服务端默认以 UTC 存储时间戳，无需改服务端时区，但客户端必须通过
timezone参数告知其本地时区以便正确解析
验证与排查关键点
不要只看“能连上”，要验证时间值是否真正一致。
- 查数据库当前时间：
SELECT NOW(), SYSDATE(), UTC_TIMESTAMP();对比结果差异 - 查数据库时区配置：
SHOW VARIABLES LIKE '%time_zone%';确认time_zone值为+08:00或Asia/Shanghai，而非SYSTEM或乱码 - 在 Java 中打印：
System.out.println(TimeZone.getDefault());和System.out.println(Instant.now());，再对比插入后查出的数据库时间值
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
