日志时间差了八小时：用同一个时间戳核对单位和时区

同一时刻可以显示成不同时间

Unix 时间戳表示相对纪元经过的时间，显示时才套用时区。1704067200 秒对应 UTC 的 2024-01-01 00:00:00，也对应上海的 2024-01-01 08:00:00。这两个显示值指向同一个时刻。

排查日志时先记录原始值、单位、显示时区。仅截图“8 点”和“0 点”不足以判断服务器时间是否错误。

做一次可重复的单位检查

将 1704067200 按秒转换，再将 1704067200000 按毫秒转换，二者应得到同一时刻。若把秒值当毫秒输入，日期会落到 1970 年附近。10 位、13 位只是现代日期常见长度，负时间戳和较早日期并不遵守这个简化规律。

new Date(1704067200 * 1000).toISOString()
// 2024-01-01T00:00:00.000Z
new Date(1704067200000).toISOString()
// 2024-01-01T00:00:00.000Z

不要把没有时区的文字当作绝对时刻

2024-01-01 08:00:00 没有说明时区。不同运行环境和解析方式可能得到不同结果。跨系统传输优先使用明确单位的整数，或者带 Z、+08:00 等偏移的标准日期字符串。

带偏移的日期字符串只描述该次的偏移；需要排班或将来的本地时间规则时，还应保留 Asia/Shanghai 这样的时区标识。涉及实行夏令时的地区，不能把某个固定偏移当成全年规则。

定位问题的最短流程

本站本地时间来自浏览器设置，无法证明服务器时区。先用 UTC 比较，若 UTC 一致而本地显示不同，应检查显示层；如果 UTC 不同，继续检查单位和原始字符串解析。

1. 在工具中明确选择秒或毫秒。
2. 保存 UTC 转换结果，与服务端 ISO 输出比较。
3. 核对浏览器时区，再比较本地显示。
4. 在接口文档中给时间字段注明单位与含义，如 createdAtMs。