MySQL 8迁移后JDBC驱动读取DST时间戳值错误求助

我之前也碰到过类似的时区坑，尤其是从MySQL 5.x升级到8.x后，JDBC驱动的时区处理逻辑变化确实容易踩雷。结合你的场景，给你几个针对性的解决方案：

1. 用Olson时区ID替换EST缩写，配置JDBC URL #

别再用EST这种静态时区缩写了——它不包含夏令时的切换规则。MySQL 8.0的JDBC驱动更依赖Olson时区数据库名称（比如America/New_York），它能自动识别DST的时间节点，处理时区转换更准确。

修改你的JDBC URL为：

jdbc:mysql://your-host:3306/your-db?serverTimezone=America/New_York&useSSL=false&allowPublicKeyRetrieval=true

这个配置会让驱动使用带DST规则的时区，读写时都会按照正确的逻辑处理，不会把2020-03-17 23:01:54错误转换为次日的00:01。

2. 统一MySQL服务器的时区设置 #

确保数据库服务器的全局和会话时区都配置为带DST的时区，这样即使JDBC URL参数有遗漏，也能保证时区一致性：

• 编辑MySQL配置文件（Linux是/etc/my.cnf或/etc/mysql/my.cnf，Windows是my.ini），添加或修改：

  [mysqld]
  default-time-zone = 'America/New_York'
  

• 重启MySQL服务
• 执行以下SQL验证时区是否生效：

  SELECT @@global.time_zone, @@session.time_zone;
  

  确认返回值都是America/New_York（或对应的Olson时区ID）

3. 修复LOAD DATA LOCAL INFILE的时区问题 #

LOAD DATA LOCAL INFILE是直接和MySQL服务器交互的命令，JDBC驱动的serverTimezone参数可能不会被应用到这个会话中。解决方法很简单：在执行导入前，显式设置会话时区：

// 先设置当前会话的时区
Statement stmt = connection.createStatement();
stmt.execute("SET time_zone = 'America/New_York';");
stmt.close();

// 再执行LOAD DATA导入命令
PreparedStatement loadStmt = connection.prepareStatement(
    "LOAD DATA LOCAL INFILE '/path/to/your/file.csv' INTO TABLE your_table ..."
);
loadStmt.execute();
loadStmt.close();

这样导入时，MySQL会用America/New_York时区解析文件中的时间字符串，避免错误的夏令时转换。

4. 升级JDBC驱动版本 #

你当前用的是8.0.18/19，建议升级到最新的mysql-connector-java 8.0.x版本（比如8.0.36）。后续版本修复了不少时区相关的bug，包括LOAD DATA时参数被忽略的问题，可能直接解决你的痛点。

为什么MySQL 5.1时没有这个问题？ #

MySQL 5.1的时区处理逻辑比较宽松，默认依赖系统时区且对DST的校验不严格，很多隐性问题被掩盖了。而MySQL 8.0和对应的JDBC驱动遵循了更严格的SQL标准，对时区一致性要求更高，所以之前的隐性问题在迁移后就暴露出来了。

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