⭐⭐⭐ Spring Boot 项目实战	⭐⭐⭐ Spring Cloud 项目实战
《Dubbo 实现原理与源码解析 —— 精品合集》	《Netty 实现原理与源码解析 —— 精品合集》
《Spring 实现原理与源码解析 —— 精品合集》	《MyBatis 实现原理与源码解析 —— 精品合集》
《Spring MVC 实现原理与源码解析 —— 精品合集》	《数据库实体设计合集》
《Spring Boot 实现原理与源码解析 —— 精品合集》	《Java 面试题 + Java 学习指南》

摘要: 原创出处 juejin.cn/post/7221740907232657468 「钰紫薇」欢迎转载，保留摘要，谢谢！

🙂🙂🙂关注微信公众号：【芋道源码】有福利：

RocketMQ / MyCAT / Sharding-JDBC 所有源码分析文章列表

RocketMQ / MyCAT / Sharding-JDBC 中文注释源码 GitHub 地址

您对于源码的疑问每条留言都将得到认真回复。甚至不知道如何读源码也可以请教噢。

新的源码解析文章实时收到通知。每周更新一篇左右。

认真的源码交流微信群。

最近有一个新项目上线，在上线时，突然发现时间与正常时间对不上，少了八个小时；但我丝毫不慌，这不就是个时区的问题吗，简单，但是这一次它给我深深的上了一课，一起来看整个排查过程吧。

开始排查

排查数据库

一般的时区问题都是数据库配置或数据链接参数的配置问题，于是我立马就定位到了问题，应该是数据库的时区设置错了，于是我愉快的查看了数据库时区

❝

命令：show variables like ‘%time_zone%’;

❞

1、system_time_zone：全局参数，系统时区，在MySQL启动时会检查当前系统的时区并根据系统时区设置全局参数system_time_zone的值。值为CST，与系统时间的时区一致。

2、time_zone：全局参数，设置每个连接会话的时区，默认为SYSTEM，使用全局参数system_time_zone的值。

CST时间

CST时间：中央标准时间。CST可以代表如下4个不同的时区：

Central Standard Time (USA) UT-6:00，美国
Central Standard Time (Australia) UT+9:30，澳大利亚
China Standard Time UT+8:00，中国
Cuba Standard Time UT-4:00，古巴

再次分析

很显然，这里与UTC时间无关，它只是时间标准。目前Mysql中的system_time_zone是CST，而CST可以代表4个不同的时区，那么，Mysql把它当做哪个时区进行处理了呢？

简单推算一下，中国时间是UT+8:00，美国是 UT-6:00，当传入中国时间，直接转换为美国时间（未考虑时区问题），时间便慢了14个小时。

既然知道了问题，那么解决方案也就有了。

解决方案

方案一：修改数据库时区

既然是Mysql理解错了CST指定的时区，那么就将其设置为正确的。

连接Mysql数据库，设置正确的时区：

set global time_zone = '+8:00';
set time_zone = '+8:00';
flush privileges;

再次执行show命令查看：show variables like '%time\_zone%';。

这里我选择方案2：修改数据库连接参数

# 原配置
serverTimezone=GMT%2B8
##修改 serverTimezone=Asia/Shanghai 

url: jdbc:mysql://localhost:3306/aurora_admin?useUnicode=true&characterEncoding=utf8&zeroDateTimeBehavior=convertToNull&useSSL=true&serverTimezone=Asia/Shanghai&autoReconnect=true&rewriteBatchedStatements=true&allowMultiQueries=true

到这里，我想着问题肯定已经解决了；愉快的测了一手；结果还是差八个小时？但是本地项目的时间是正常的啊，我开始有了不祥的预感; 于是我本地连上线上的数据库开始测试，发现时间是正常的。到这里，就基本排查出不是MySQL的问题。

排查 Linux

我开始怀疑是不是 linux 系统的时区有问题；

❝

查看硬件的时间：hwclock –show

❞

❝

查看系统的时间：date -R

❞

发现Linux的时间四年没问题的，于是开始查服务器的时区配置查看时区 TZ配置：echo $TZ

发现为空，于是查看系统配置；查看系统配置命令：env

发现确实没有 TZ 的配置，系统并未设置TZ变量，而是通过localtime指定时区；于是我修改 localtime的指定。

❝

先删除TZ环境变量：unset TZ

❞

❝

再执行：ln -sf /usr/share/zoneinfo/Asia/Shanghai /etc/localtime 命令etc目录下创建名称是localtime的快捷键指定到上海时区文件上；

❞

修改完成后，果断重启项目测试，结果令人失望，时间依旧没有变化，于是尝试直接加上 TZ配置

❝

命令：export TZ=Asia/Shanghai

❞

再次查看：

可以看到 TZ配置已经设置成功，到这里我似乎看到了希望；于是再次测试，然后我人傻了，时间依旧少八个小时；到这里，我实在是不知道还有什么是没排查的了，于是脑海里重新过一遍排查的过程。

1、本地连线上的数据库测试是正常的，所以数据库肯定是没问题的 2、项目程序也没问题：@JsonFormat(）并没有指定其他时区，字段类型也对的上；3、Linux时间也没问题，时区也设置了；

排查Docker

我突然想到项目是通过Docker 来构建的，难道是Docker内部的时区有问题，这是唯一还没有排查的地方了，于是查看Dockerfile配置文件！

很简单的配置呀，没理由出问题呀，为了保险起见；决定手动给他指定一个时区，最终的配置文件；添加配置：

# 安装tzdata(如果 设置时区不生效使用)
# RUN apk add --no-cache tzdata
# 设置时区
ENV TZ="Asia/Shanghai"

重新构建项目运行，再次测试，时间正常了。

芋道源码 —— 纯源码解析博客

线上系统时间慢八个小时的排查之路