Java操作MySQL timestamp字段因夏令时出现2小时时间偏差问题咨询

问题原因解答 #

1. 服务端全程UTC时区前提下，java.sql.Timestamp和MySQL是否会受夏令时影响？

• java.sql.Timestamp本身存储的是UTC时间戳，不携带时区信息，不会直接受夏令时影响。但两个环节会引入夏令时偏差：
  • 如果你在计算时间、转换时间格式时使用了Calendar、SimpleDateFormat等默认取JVM时区的API，一旦JVM时区不是UTC，就会触发夏令时偏移计算。
  • MySQL的timestamp类型本质是存储UTC时间戳，但写入/读取时会自动按MySQL会话时区做转换。如果JDBC连接没有强制指定会话时区为UTC，会默认取MySQL服务器时区/操作系统时区/JVM时区，只要该时区有夏令时规则，就会影响最终存储的值。

2. 为什么AEST夏令时切换会影响UTC时区的服务端逻辑？

你遇到的问题核心是两个隐藏的时区配置不一致：

• 第一是MyServiceUtils.calculateNoOfDaysInMonth的实现大概率没有强制指定UTC时区，而是用了JVM默认时区（可能是AEST，或者取了用户请求携带的AEST时区），计算月份长度时自动带入了夏令时的时间偏移，导致你算出的总毫秒数本身就和预期的N*86400000L有偏差。
• 第二是JDBC连接没有显式配置serverTimezone=UTC&useLegacyDatetimeCode=false参数，JDBC驱动在传输Timestamp时，会自动按默认时区（AEST）做转换，相当于两次时区偏移叠加。
  你以为的全程UTC只是业务代码里的时间值是UTC，但工具类、JDBC驱动两个环节偷偷用了AEST时区，自然会受夏令时影响。

3. 为什么偏差是2小时而非1小时？

澳大利亚东部时区的夏令时偏移变化会产生两次偏移差：

• 2021年4月3日你操作的时间点还处于夏令时（AEDT），和UTC的偏移是+11；到5月3日已经切换为冬令时（AEST），和UTC的偏移是+10，两个时间点本身的时区偏移就差了1小时。
• 如果你读取原始refresh_time时JDBC用了AEST时区转成了本地时间再计算，写入时又做了一次时区转换，两次偏移叠加就会产生2小时的偏差。

修复方案 #

1. 替换时间计算逻辑：不要用加N天毫秒数的方式实现“加一个月”的需求，这种方式默认每天固定86400秒，本身就不兼容夏令时、闰秒等场景。建议使用Java 8+的java.timeAPI，强制指定UTC时区计算：

// 从数据库取出的原始时间
Instant originalTime = resultSet.getTimestamp("refresh_time").toInstant();
// 加一个月，强制用UTC时区计算
Instant nextMonthTime = originalTime.atZone(ZoneOffset.UTC)
        .plusMonths(1)
        .toInstant();
// 转成Timestamp传入数据库
Timestamp periodRefresh = Timestamp.from(nextMonthTime);

2. 强制JDBC连接参数，确保会话时区为UTC：

jdbc:mysql://your_host:3306/your_db?serverTimezone=UTC&useLegacyDatetimeCode=false

3. 检查所有时间工具类的实现，确保所有时间格式化、计算逻辑都显式指定UTC时区，不要使用默认时区。

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