Ubuntu 时区与 NTP 配置：显示时间和系统时钟分开检查
日志显示凌晨，业务团队却说问题发生在上午，这可能只是时区差异；证书校验、任务调度和认证都异常时，则需要进一步检查系统时钟。本文以 Ubuntu 24.04 为例，先识别当前同步服务，再处理时区或时间源。不同镜像可能使用 timesyncd、chrony 或平台提供的其他方案，不应同时让多个程序争抢同一个时钟。
先区分时间点与显示方式
在服务器执行：
date --iso-8601=seconds
date -u --iso-8601=seconds
timedatectl status
本地时间和 UTC 可以显示不同小时，但仍表示同一时间点。时区设置控制显示转换，通常不是修复时钟漂移的方法。先把业务日志、应用日志和告警使用的时区记录清楚，再判断是否存在真正的时间偏差。
跨地区业务可以统一在记录中保存明确时区或 UTC，在查看时转换。不要为了让所有截图看起来一样，就在故障处理中临时来回修改服务器时区。
修改时区前确认定时任务影响
如果确实需要调整显示时区，先用 timedatectl list-timezones 查询可用名称，并记录原值。例如计划采用中国标准时间，可以在确认后执行：
# Ubuntu 服务器，确认计划与原时区后执行
sudo timedatectl set-timezone Asia/Shanghai
timedatectl status
修改后检查 cron、systemd 日历任务、数据库和应用的时间解释。某些程序采用自己的时区设置，并不会完全跟随系统变化。存在夏令时的地区还要考虑某些本地时刻重复或不存在的情况。timedatectl 手册说明了时区与同步控制接口。
回退时使用事先记录的原时区，再核对下一次任务时间。不要只改显示而忽略业务已经安排好的计划。
确认谁在同步系统时钟
检查 systemctl status systemd-timesyncd chrony --no-pager，服务不存在时出现相应提示，不代表整个时间系统失败。再结合已安装软件、运行状态和平台说明确认真正的管理者。
timedatectl 中 NTP 服务启用与系统已经同步是不同状态。刚启动、网络不可达或时间源无效时，服务可以运行但尚未得到有效同步。先查服务日志和当前来源，而不是反复手工设时。
对于虚拟机，还要了解宿主机时间同步组件是否参与校时。发现多套机制时应按平台支持方案统一管理，不随意卸载正在提供同步的组件。
timesyncd 环境中检查实际时间源
仅在已确认使用 systemd-timesyncd 的服务器上，查看 timedatectl timesync-status 和对应服务日志。需要指定企业时间源时，先备份配置，采用独立配置片段。目录不存在时先执行 sudo mkdir -p /etc/systemd/timesyncd.conf.d，再将下面内容保存到 /etc/systemd/timesyncd.conf.d/60-time-sources.conf；该文件若已存在应先检查并备份，示例中的域名必须换成真实可用的时间服务器：
[Time]
NTP=time1.example.com time2.example.com
网络侧要允许所需的时间同步流量，并确认 DNS 正常。配置中的候选来源与实际选中的来源不一定相同，也可能受链路配置影响。timesyncd.conf 手册说明了各来源字段及回退行为。
应用配置后按维护流程重新加载或重启对应同步服务，再观察来源、偏差和日志。时间偏差很大时，校正可能影响业务计时，应安排窗口，不把强制手工跳时作为常规排障方法。
用持续结果验收而不是只看一次状态
同步成功后，继续观察一段时间，并检查重启、网络恢复后是否能重新选择来源。把业务时间误差、同步来源不可用和定时任务失败作为不同告警，避免一个“服务运行中”覆盖全部问题。
如果新时间源不可达，恢复原配置并确认原来源重新工作。不要长期留下只有示例域名的配置，也不要随意关闭同步来消除日志报错。最后保存系统时区、应用时区、同步机制和维护负责人，下次排查跨地区日志时就能从同一口径开始。