云主机与网页时间相差8小时：一次UTC时区排查

核对网页操作记录时，我遇到一个容易判断错的问题：记录显示在 00:35 完成，而按北京时间看，实际对应早上 08:35。页面中的任务已经完成，积分也能对上，只有时间看起来不一致。

这次排查使用 Ubuntu 24.04 和 Chrome。最后确认：系统与浏览器都使用 UTC，网页按浏览器时区格式化记录。把同一条记录分别放在 UTC 和 Asia/Shanghai 下查看，显示时间正好相差8小时。

下面把检查过程拆开说明。排查时先保留原有设置，这样能分清差异来自系统、浏览器，还是业务本身。

先看系统输出是否带时区

在终端执行：

date -Iseconds
timedatectl show -p Timezone

本次实际输出为：

2026-11-11T02:21:13+00:00
Timezone=Etc/UTC

日期末尾的 +00:00 表示 UTC 偏移为零；北京时间对应 +08:00。因此，这里的 02:21:13 对应北京时间 10:21:13。

如果只想临时用北京时间查看当前时刻，可以给这一条命令指定环境变量：

TZ=Asia/Shanghai date -Iseconds

这条命令只改变该进程的时间显示方式，不会修改整台机器的系统时区。

为了避免两条命令之间经过几秒钟而干扰对比，也可以转换一个固定时间：

TZ=UTC date -d '2026-11-11T00:35:00Z' -Iseconds
TZ=Asia/Shanghai date -d '2026-11-11T00:35:00Z' -Iseconds

两行分别显示：

2026-11-11T00:35:00+00:00
2026-11-11T08:35:00+08:00

它们表示同一个时刻。

网页的时区需要单独确认

系统设置可以作为线索，浏览器实际使用的时区仍应单独检查。在 Chrome 开发者工具的 Console 中运行：

Intl.DateTimeFormat().resolvedOptions().timeZone
new Date().getTimezoneOffset()

本次结果分别是 UTC 和 0。

getTimezoneOffset() 的返回单位是分钟，方向为 UTC 减去本地时间。因此，使用北京时间时通常会看到 -480，这里的负号是正常结果。

仅知道浏览器使用 UTC，还不能判断所有网页都按 UTC 展示。页面可能使用浏览器默认时区，也可能固定按业务时区格式化，甚至直接显示接口返回的字符串。

为确认这一点，我在开发者工具中临时覆盖页面时区，重新打开同一组记录，得到下面的对照：

恢复 UTC 后，页面又显示原来的时间。由此可以确定，这个页面的记录时间会跟随浏览器时区变化。测试结束后，我恢复了浏览器原有设置。

这个实验验证的是记录的显示方式。每日任务在哪个时刻重置，仍需依据网站的业务规则，不能单凭页面显示时间判断。

自己开发页面时，明确指定展示时区

如果业务要求所有用户都按北京时间查看记录，可以在格式化时明确传入 timeZone：

const instant = new Date("2026-11-11T00:35:00Z");

const formatter = new Intl.DateTimeFormat("zh-CN", {
  timeZone: "Asia/Shanghai",
  year: "numeric",
  month: "2-digit",
  day: "2-digit",
  hour: "2-digit",
  minute: "2-digit",
  second: "2-digit",
  hourCycle: "h23"
});

console.log(formatter.format(instant));

这段代码输出 2026/11/11 08:35:00。即使运行环境的默认时区是 UTC，结果也按北京时间显示。

接口中的时间同样需要明确含义。ISO 8601 字符串可以保留 Z 或 +08:00 这样的偏移信息。对于来源不明的 2026-11-11 08:35:00，应先确认它属于哪个时区，再做解析；直接补上 Z 会把它解释成 UTC，可能再次造成8小时偏差。

定时任务也把业务时区写清楚

如果云主机保持 UTC，而任务希望每天北京时间 09:00 执行，可以在 systemd timer 的日历表达式中写明时区：

[Timer]
OnCalendar=*-*-* 09:00:00 Asia/Shanghai

配置前，先用下面的只读命令检查表达式：

systemd-analyze calendar '*-*-* 09:00:00 Asia/Shanghai'

本次在北京时间 2026年11月11日10点之后运行，输出中的下一次触发时间是：

Normalized form: *-*-* 09:00:00 Asia/Shanghai
    Next elapse: Thu 2026-11-12 01:00:00 UTC

这里的 UTC 01:00 对应北京时间 09:00，符合预期。这个命令只验证表达式，不会创建或启动定时任务。以上 timer 片段需要配套实际的 service 才能执行工作。

这次排查最有用的步骤，是始终拿同一个时刻进行对照：先看系统输出的偏移，再查浏览器时区，最后重新打开同一条网页记录。确认显示转换正确后，再核对任务的业务日期和触发规则，问题就容易定位得多。

参考资料：

• systemd：timedatectl
• systemd：时间与日历表达式
• ECMAScript 国际化 API：DateTimeFormat