宝塔面板无法修改系统时区，主因是systemd-timesyncd强制同步、Docker默认UTC或/etc/localtime链接错误；应先停用timesyncd，再用timedatectl set-timezone Asia/Shanghai设置，并同步更新PHP/Python应用时区配置。
宝塔面板里改不了系统时区？先看是不是被容器或 systemd 锁住了
宝塔面板本身不直接管理服务器底层时区，它只是个 Web 管理界面。你点「系统设置」→「修改时区」没反应，或者改完重启又变回 UTC，大概率是系统级时区配置被覆盖了。常见原因是：Docker 容器默认用 UTC、systemd-timesyncd 强制同步、或者 /etc/localtime 是硬链接但指向错了。
- 先执行
timedatectl status，看输出里的Time zone和System clock synchronized状态 - 如果显示
UTC且systemd-timesyncd正在运行，它可能每小时重置一次时区——得先停掉：systemctl stop systemd-timesyncd，再禁用：systemctl disable systemd-timesyncd - 检查
/etc/localtime是否为软链接：ls -l /etc/localtime；如果不是指向/usr/share/zoneinfo/Asia/Shanghai这类路径，就手动重建：ln -sf /usr/share/zoneinfo/Asia/Shanghai /etc/localtime
Linux 命令行改时区最稳的方式：用 timedatectl 而不是复制文件
直接拷贝 zoneinfo 文件或改 /etc/timezone 在新系统（尤其是 CentOS 8+/Ubuntu 20.04+）上容易失效，因为 timedatectl 才是 systemd 推荐的统一接口。它会自动处理符号链接、硬件时钟（RTC）设置、以及通知所有依赖服务。
- 查可用时区：
timedatectl list-timezones | grep Shanghai - 设为东八区：
timedatectl set-timezone Asia/Shanghai - 确认生效：
timedatectl | grep "Time zone"，输出应为Asia/Shanghai (CST, +0800) - 注意：如果服务器硬件时钟（RTC）设为本地时间而非 UTC，可能导致双系统（如 Windows 共存）时间错乱，建议保持 RTC 为 UTC：
timedatectl set-local-rtc 0
PHP/Python 应用仍显示 UTC 时间？那是应用层没读系统时区
改完系统时区后，PHP 的 date() 或 Python 的 datetime.now() 还是 UTC，说明应用没继承系统设置。尤其 PHP-FPM 子进程常缓存旧环境变量，Python 的 tzlocal 库也可能 fallback 到 UTC。
- PHP：检查
php.ini中是否显式写了date.timezone = UTC，删掉或改成date.timezone = Asia/Shanghai，然后重启php-fpm - Python：不要只靠
datetime.now()，用datetime.now().astimezone()或显式加载时区：from zoneinfo import ZoneInfo; datetime.now(ZoneInfo("Asia/Shanghai")) - Node.js：环境变量
TZ=Asia/Shanghai必须在启动前生效，比如 PM2 启动时加--env TZ=Asia/Shanghai
宝塔计划任务（crontab）时间不准？和系统时区、面板设置两层有关
宝塔的「计划任务」界面里设置的“每天 2:00 执行”，这个 2:00 是按服务器系统时区解析的，但如果你在面板里又单独设置了「面板时区」（右上角头像 → 面板设置 → 时区），那只是影响面板 UI 显示，不影响 cron 实际触发时间。
- 验证 cron 实际运行时间：在任务脚本开头加
echo "$(date)" >> /www/wwwlogs/cron-test.log，观察日志时间是否符合预期 - 确保系统时区已正确设置（见前两节），否则
crond进程只会按/etc/localtime解析时间 - 宝塔自建的定时任务本质是写进
/var/spool/cron/root，别手动去改这个文件，用宝塔界面增删，避免权限或格式错误
date.timezone、没停掉 systemd-timesyncd、或者 cron 日志里的时间看起来对了，其实是面板 UI 把 UTC 当成 CST 显示出来的假象。 
