用 timedatectl set-timezone 是唯一可靠方式，它同步更新 /etc/localtime 软链接、通知内核并重载相关服务；手动 ln -sf 易遗漏后续步骤，导致部分进程仍读错时区。
直接改 /etc/localtime 软链接，不是复制文件，也不是改配置文件内容。
为什么用 timedatectl set-timezone 而不是手动改 /etc/localtime
现代 Linux（systemd 系统）里，timedatectl 是唯一可靠方式：它会同步更新 /etc/localtime 软链接、通知内核、触发时区相关服务重载。手动删软链接再 ln -sf 容易漏掉后半步，导致 date 显示对了但 Java/Python 进程仍读错时区。
-
timedatectl set-timezone Asia/Shanghai是标准做法 - 执行后立刻生效，无需重启
- 支持 tab 补全时区名：
timedatectl list-timezones | grep -i shang - 旧系统（sysvinit）才需要手动 ln -sf /usr/share/zoneinfo/Asia/Shanghai /etc/localtime
Asia/Shanghai 和 Asia/Chongqing 有区别吗
没有实际区别 —— 它们指向同一个二进制时区数据文件。Linux 时区数据库里，Asia/Shanghai 是官方推荐名，Asia/Chongqing 是别名（alias），两者内容完全一致。选哪个都行，但建议统一用 Asia/Shanghai，避免团队协作时混淆。
- 验证方式：
ls -l /usr/share/zoneinfo/Asia/{Shanghai,Chongqing}会显示相同 inode - 别用
PRC（已废弃）、GMT+8（非 IANA 标准，不支持夏令时逻辑） - 容器内设置时区，优先挂载
/usr/share/zoneinfo/Asia/Shanghai到/etc/localtime，而非写死环境变量
改完发现 date 没变，或者日志时间还是错的
常见原因不是命令没执行成功，而是进程缓存了旧时区或没重读环境。尤其 Java、Python、Node.js 这类运行时，启动时读一次 TZ 或系统时区，之后不会自动更新。
- 检查是否真生效：
timedatectl status | grep "Time zone" - 确认硬件时间是否设为本地时间（罕见但致命）：
timedatectl | grep "RTC in local TZ"，若为 yes，需执行timedatectl set-local-rtc 0 - Java 应用必须重启，或启动时加
-Duser.timezone=Asia/Shanghai - Python 的
datetime.now()默认用系统时区，但time.time()返回的是 UTC 秒数，别拿它直接比对“当前小时”
真正麻烦的不是改时区本身，而是改完后哪些进程根本没感知到变化 —— 尤其是长期运行的守护进程、容器、或者用 fork() 后没重设时区的子进程。别只信 date 命令输出。
