Linux 服务器时间不对？宝塔数据库备份还是 UTC？一篇彻底讲清楚（小白必看）

很多人第一次登录服务器，会遇到这些问题：

• date 显示的是 UTC，少 8 小时
• 已经改了系统时区，但 宝塔数据库备份时间还是不对
• 日志时间乱、定时任务跑偏、MySQL 时间不一致

别急，这不是你一个人的问题。
这篇文章从 原理 → 操作 → 宝塔专项坑位，一步一步带你彻底解决。

一、为什么服务器时间默认是 UTC？

大多数云服务器、海外镜像、官方系统，默认使用 UTC：

• UTC 是世界标准时间
• 中国北京时间 = UTC + 8 小时
• 服务器统一用 UTC，跨时区更安全、更稳定

但如果你：

• 在国内
• 日志、排查、业务都以北京时间为准

👉 那就应该把 系统本地时区 改成 Asia/Shanghai。

二、先搞清楚：服务器现在到底用的是什么时间？

不要只看 date，一定要看 timedatectl。

timedatectl

如果你看到类似这样：

Local time: Thu 2026-02-05 02:16:30 UTC
Universal time: Thu 2026-02-05 02:16:30 UTC
Time zone: Etc/UTC (UTC, +0000)
System clock synchronized: yes
NTP service: active

说明：

• 当前 系统本地时区是 UTC
• NTP 同步是正常的（这是好事）

三、一步把服务器改成北京时间（推荐方式）

1️⃣ 设置时区为 Asia/Shanghai

sudo timedatectl set-timezone Asia/Shanghai

2️⃣ 立刻验证

timedatectl
date

你应该看到：

Local time: Thu 2026-02-05 10:16:44 CST
Universal time: Thu 2026-02-05 02:16:44 UTC
Time zone: Asia/Shanghai (CST, +0800)
System clock synchronized: yes

以及：

Thu Feb 5 10:16:44 AM CST 2026

✅ 说明系统时区已成功切换
✅ 不需要重启服务器

四、这是“正确且推荐”的生产配置吗？

是的，而且是教科书级配置：

• 系统本地时间：Asia/Shanghai（北京时间）
• UTC 时间：正常保留
• NTP：开启并同步
• RTC（硬件时钟）：保持 UTC

你可能会看到这一行：

RTC in local TZ: no

👉 这是好事，不是问题。

五、Docker / Jenkins / Java 时间还是不对？（非常常见）

系统时间对了，不代表所有应用都对了。

1️⃣ Docker 容器里查看时间

docker exec -it 容器名 date

2️⃣ Docker 推荐设置时区（启动容器时）

-e TZ=Asia/Shanghai

或：

-v /etc/localtime:/etc/localtime:ro

👉 Jenkins 容器建议两种都用，更稳。

3️⃣ Java / Spring Boot 时间慢 8 小时？

Java 可能仍使用 UTC。

JVM 启动参数（强烈建议）

-Duser.timezone=Asia/Shanghai

示例：

java -Duser.timezone=Asia/Shanghai -jar app.jar

Spring Boot（可选）：

spring:
jackson:
time-zone: Asia/Shanghai

六、MySQL 时间不对？（单独一层）

系统时间对了，MySQL 也可能还是 UTC。

1️⃣ 检查 MySQL 时区

show variables like '%time_zone%';

如果看到：

system_time_zone = UTC
time_zone = SYSTEM

说明 MySQL 启动时读的是旧时区。

2️⃣ 临时修复（立即生效，重启失效）

set global time_zone = '+08:00';

3️⃣ 永久修复（推荐）

宝塔 MySQL 配置一般在：

/www/server/mysql/my.cnf

加入：

[mysqld]
default-time-zone = '+08:00'

然后重启 MySQL：

service mysqld restart

七、重点坑位：宝塔数据库备份时间还是 UTC，为什么？

这是最容易卡人的地方。

你会发现：

• 系统 date 已经是 CST
• 但宝塔「数据库备份」显示的时间还是不对

👉 原因通常不是一个，而是 宝塔有自己的执行环境。

原因一（最常见）：宝塔面板缓存了旧时区

宝塔在启动时会读取系统时区。

如果你是：

先启动宝塔 → 后修改系统时区

那宝塔还在用旧的 UTC。

✅ 解决方法（90% 的人到这一步就好了）

bt restart

或：

service bt restart

然后：

• 再执行一次数据库备份
• 或等下一次自动备份

原因二：宝塔定时任务（cron）环境不一致

宝塔数据库备份是通过 cron 定时任务 触发的。

你可以检查：

crontab -l

有些环境下，cron 使用的时区和系统不完全一致。

👉 高级用法（了解即可）：

CRON_TZ=Asia/Shanghai

原因三：MySQL 自己还在用 UTC（很常见）

即使系统和宝塔对了，MySQL 仍可能是 UTC。

一定要执行：

show variables like '%time_zone%';

并按上面 第六节 处理。

原因四（极少见）：备份脚本里写死了 UTC

老版本脚本可能用：

date -u

排查：

grep -R "date -u" /www/server/panel/script/

这种情况建议 升级宝塔版本，不推荐小白手改脚本。

八、5 分钟万能排查清单（直接复制）

# 系统
date
timedatectl

# 重启宝塔（关键）
bt restart

# Docker（如有）
docker exec -it 容器名 date

# MySQL
mysql -uroot -p
show variables like '%time_zone%';

九、一句话总结（可以直接对同事/领导说）

服务器系统时区已切换为 Asia/Shanghai，但宝塔面板、定时任务或 MySQL 在启动时缓存了旧时区，需要重启宝塔并确认数据库时区配置，之后备份时间即可与系统时间保持一致。

十、写在最后

时间问题不是“有没有改时区”这么简单，而是：

系统 → 宝塔 → 定时任务 → 容器 → JVM → 数据库
哪一层没统一，时间就会乱。