转载自鹏说大数据
关键词： 大数据、数据调度、任务组、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）。
