Spring Boot集成Docker版MySQL时树莓派实例查询TIME字段偏移1小时异常问题

观测到的固定1小时TIME字段偏差，本质是数据从MySQL流向Spring Boot应用的链路中，多个时区配置环节不统一，被JDBC驱动、Hibernate组件隐式做了时区转换，和MySQL内部实际存储的原始值无关。
这里需要纠正一个常见认知误区：很多人认为MySQL的TIME类型是纯字符串格式、不带时区属性，不会发生时区转换——实际上Connector/J 8.x版本为了统一处理时间类型的读写逻辑，会对所有返回的时间类字段（包括TIME类型）按连接配置的时区规则做偏移转换，这也是明明数据库CLI里查到的存储值完全一致，应用读出来却有偏差的核心原因。

所有排查动作不要依赖宿主机时区感知，逐层确认链路每个节点的实际生效配置：

• 第一优先级：确认Docker容器内MySQL的实际时区配置
  Docker容器是文件系统、环境完全隔离的，很多开发者习惯性挂载宿主机的/etc/localtime到容器实现时区同步，但这会导致容器时区和宿主机强绑定，在不同宿主机上出现配置差异。分别进入两个环境的MySQL容器内部执行以下命令比对结果：
  • 执行SELECT @@global.time_zone, @@session.time_zone; 查看MySQL服务端的全局、会话级时区配置
  • 执行SELECT @@system_time_zone; 查看容器启动时加载的系统时区值
    目前观测到的1小时偏差刚好和树莓派、Ubuntu的宿主机时区差完全匹配，大概率是树莓派上的MySQL容器因为挂载了宿主机的UTC+1时区，和Ubuntu上默认UTC时区的容器配置出现了偏移。
• 第二优先级：检查JDBC连接的实际生效时区参数
  Connector/J 8.x版本如果没有显式指定serverTimezone连接参数，会自动从MySQL服务端拉取时区配置，自动完成服务端到应用端的时区转换。比对两个环境下Spring Boot启动日志里打印的JDBC连接配置，确认实际生效的serverTimezone值是否存在1小时的时区差。
• 第三优先级：检查Hibernate的时区映射配置
  确认应用配置中是否存在spring.jpa.properties.hibernate.jdbc.time_zone参数，如果没有显式配置，Hibernate会自动取当前JVM进程的默认时区做转换——树莓派上的JVM进程因为宿主机是UTC+1时区，自动加载对应时区，和Ubuntu上默认UTC的JVM时区形成1小时差，就会触发TIME字段值的偏移。

核心思路是全链路统一时区配置，禁止依赖组件自动探测时区的逻辑，彻底消除不同宿主机环境带来的配置差异：

• Docker MySQL层面：启动容器时显式通过环境变量指定时区，比如配置TZ=UTC，不要依赖挂载宿主机时区文件的方式做同步，保证两个环境的MySQL容器内部时区完全一致，不受宿主机时区影响
• JDBC连接层面：数据库连接串中显式添加serverTimezone=UTC参数，强制按UTC完成连接级别的时区映射，禁止驱动自动探测MySQL服务端时区
• Hibernate层面：在应用配置中统一添加参数spring.jpa.properties.hibernate.jdbc.time_zone=UTC，禁止Hibernate自动取JVM时区做字段值转换
• JVM启动层面：Spring Boot应用启动时显式添加启动参数-Duser.timezone=UTC，避免不同宿主机的系统时区差异影响JVM的默认时区

快速验证方法：可以先临时在树莓派的Spring Boot启动命令中加入-Duser.timezone=UTC参数重启服务，再查询TIME字段的返回值，如果1小时偏差消失，即可直接确认是链路时区配置不统一导致的问题，无需排查其他无关环节。

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