必看！Apache DolphinScheduler 任务组因 MySQL 时区报错全解析与避坑指南
转载自鹏说大数据
关键词： 大数据、数据调度、任务组、MySQL时区
整体说明
在项目上实际使用了 DolphinScheduler 一段时间后，我遇到了任务组功能因为 MySQL 时区的原因报错的问题。经过探索这个问题已经解决了，解决思路分享如下。
问题背景
- 设置任务组调度任务
任务组是把任务分组，每批任务可以拥有自己的资源量，可以更加灵活的调配资源。
- 任务组更新时间会随着任务运行更新
只要任务更新，任务运行，等等，都会使得任务组的更新时间更新，可以看到更新时间都是最新的，这个也就是触发原因。当然没有这个，也会触发，只是会晚一点 
问题现象
- 任务调度执行报错
任务正常调度执行时，有大批量的错误，并且后台报错如下：
- 新增任务无法选择任务组
编辑任务时，无法选择具体的任务组，且会出现 “quey task group list error” 的报错信息字样
- 任务组无法查询部分数据
当我查询任务组时，前两页没问题，当要翻页到第3页时，也会报前面同样的错误。
问题分析
1. 时区配置问题
由前面的报错信息，分析得知，是获得时区问题，导致无法查询 update_time 的值
[ERROR] 2025-03-11 08:41:21.824 +0800 org.apache.dolphinscheduler.api.exceptions.ApiExceptionHandler:[52] - query task group list error
org.springframework.dao.TransientDataAccessResourceException: Error attempting to get column 'update_time' from result set. Cause: java.sql.SQLException: HOUR_OF_DAY: 2 -> 3
; HOUR_OF_DAY: 2 -> 3; nested exception is java.sql.SQLException: HOUR_OF_DAY: 2 -> 3
2. 数据库服务设置
到底设置的是什么时区呢？先查询下 MySQL 数据库的时区，执行如下 SQL ，可得知，设置的时区和系统一致，使用的是 CST
show variables like '%time_zone%';
3. 程序连接数据库设置
那么程序设置的时区是什么呢？由程序设置可知，并没有特定指定使用什么时区。
4. CST导致问题根本原因
那这时候程序就会解析 数据库服务的时区，作为自己的时区
那么会解析成什么呢？
查询了 CST 的定义，才发现问题的根源
CST 是多个时区的缩写：
- 中国标准时间：UTC+8（无夏令时）
- 北美中部时间：UTC-6（有夏令时，如美国芝加哥）
- 澳大利亚中部时间：UTC+9:30（有夏令时）
如果 MySQL 的system_time_zone设置为CST，但应用或 JDBC 驱动将其错误解析为北美中部时间（而非中国标准时间），就会导致时间转换冲突。
5. 夏令时时间范围
那为什么，之前这个问题不出现，一直到 2025-03-09 这天才开始出现呢？
于是我查询了一下 夏令时 的时间范围，才恍然大悟
北美地区
- 美国（除亚利桑那州大部分地区、夏威夷等）：
- 开始：3月第二个星期日凌晨2:00（时钟拨快1小时 → 3:00）。
- 结束：11月第一个星期日凌晨2:00（时钟拨回1小时 → 1:00）。
也就是 3月的 第二个星期日，才会出现这个问题，正好和我出问题的时间一致了，所以应该是应用系统，把 CST 解析成 北美中部时间 了，导致有夏令时
6.UTC 和 Asia/Shanghai 区别
现在明确是 时区 的问题了，那么我改修改成哪个时区呢？
我得到了两个推荐值 UTC 和 Asia/Shanghai ，于是查了资料，得到了如下对比结果
-
基本定义
![]()
-
时区偏移
![]()
-
夏令时（DST）
![]()
-
使用场景
![]()
从这个结果来看，使用 Asia/Shanghai 是最优的结果
7. 问题分析结论
由前面的分析可得，需要把 应用的 时区，修改为 Asia/Shanghai 即可
解决方案
前面分析得到结果，但是具体改怎么修改应用的时区呢？
1. MySQL服务端
第一种就是把 服务端的时区 CST 修改为 UTC，有多种方法，比如修改配置文件，还有就是 执行 SQL 如下：
SET GLOBAL time_zone = 'UTC';
当然这些都是在权限足够高的情况下。
2. JDBC连接
第二种就是修改 JDBC 连接。
在应用连接数据库的 JDBC 配置中增加如下配置：
&serverTimezone=Asia/Shanghai
效果如下： 
3. 升级JDBC 版本
如果还没有解决，可以尝试升级JDBC版本，旧版本 MySQL Connector/J（如 5.x）可能未正确处理某些时区的夏令时规则，升级到 8.x 版本 可解决多数时区问题
最终解决
由于生产上修改数据库的配置，可能对其他应用造成影响，所以最终选择了 修改 JDBC 连接的方式，解决了这个问题。
经验总结
-
对时区设置理解不深。 很早之前我就知道
serverTimezone=Asia/Shanghai这个参数，但是对这个参数的作用，和带来的影响，并不太清楚，经过这次排查，彻底弄清楚了。 -
连接信息必须增加时区配置 对 Java 开发的同学，这个问题，尤为重要，虽然最初的原因是数据库的时区是 CST 导致了这一系列的问题，但是我们没法保证数据库的设置，每次都能设置正确，所以在做数据库参数配置的时候，最好是加上
serverTimezone=Asia/Shanghai这个配置，避免踩坑。
原文链接：https://blog.csdn.net/pengpenhhh/article/details/146187437
