HOUR_OF_DAY: 2 -＞ 3问题总结

科普小知识：时区小知识

问题描述

生产连续多天归档失败，查看日志发现报错如下图

问题复现

1. 将有问题的数据导入测试环境执行归档，未复现
2. 观察日志发现执行归档使用的mysql驱动为weblogic自带的mysql-connector-java-commercial-8.0.14.jar，并不是我们指定的mysql-connector-java-5.1.46.jar
3. 本地改为mysql-connector-java-commercial-8.0.14.jar进行测试，复现问题
4. 将驱动包升级为mysql-connector-java-8.0.23.jar进行测试，未复现

问题疑点

1. 为什么使用的是weblogic自带的mysql驱动包
2. 对于同样的数据mysql-connector-java-5.1.46.jar，mysql-connector-java-commercial-8.0.14.jar，mysql-connector-java-8.0.23.jar为什么执行结果不一样
3. 本地使用weblogic自带的mysql-connector-java-commercial-8.0.14.jar执行查询语句后获取DATE_START字段内容时，复现问题，同生产报错一 致，分析1000条数据中哪些数据有问题，发现1000条数据对应的时区都一样，但是2021-03-14 02:00:00到2021-03-14 02:59:59这一个小时内的 数据会报错，其他数据正常

问题解答

1. 为什么使用的是weblogic自带的mysql驱动包
   我们在setDomain.sh中指定了mysql驱动，但是中间有空格，导致该问题发生，可以在启动参数中增加 -verbose:class查看类加载过程
   正确配置为
   

2. 对于同样的数据mysql-connector-java-5.1.46.jar，mysql-connector-java-commercial-8.0.14.jar，mysql-connector-java-8.0.23.jar为什么执行结果不一样
   a. mysql-connector-java-5.1.46.jar获取到的时区为应用系统时区

   sun.util.calendar.ZoneInfo[id="Asia/Shanghai",offset=28800000,dstSavings=0,useDaylight=false, transitions=29,lastRule=null]
   

   
   
   
   
   

   b. mysql-connector-java-commercial-8.0.14.jar获取到的是服务器端的时区，而服务器端的时区为CST
   

   c. mysql-connector-java-8.0.23.jar

3. 本地使用weblogic自带的mysql-connector-java-commercial-8.0.14.jar执行查询语句后获取DATE_START字段内容时，复现问题，同生产报错一 致，分析1000条数据中哪些数据有问题，发现1000条数据对应的时区都一样，但是2021-03-14 02:00:00到2021-03-14 02:59:59这一个小时内的 数据会报错，其他数据正常
   答：2021年美国夏令时将于当地时间3月14日(周日)凌晨2:00am开始，于11月7日(周日)凌晨2:00am结束。因此在3月14日凌晨2:00am将时钟调快1小时，时钟调到3点，因此GregorianCalendar.computeTime()在计算时间时HOUR_OF_DAY实际是2但是计算后值为3，两个不相符，因此报HOUR_OF_DAY: 2 -> 3

问题解决

方式一：在使用mysql-connector-java-8.x.x.jar时url后增加时区配置，例如：spring.datasource.url=jdbc:mysql://1.1.1.1:3306/xxx?serverTimezone=Asia/Shanghai
方式二：配置指定可用驱动包
​