日志里的时间看起来差了八小时，或者接口给出的日期落在 1970 年，先检查两个独立问题：输入单位是否正确，以及结果采用哪个时区显示。
本教程使用 Unix 时间戳转换。练习用的是一个固定历史时刻，方便所有人得到相同的 UTC 结果；右侧“日期时间”按上方选择的时区解释，默认使用系统时区。
第一步：用一个固定时刻检查秒与毫秒
打开工具，在 Unix timestamp 输入框填写 1704067200，选择“秒”。UTC 结果应为：
2024-01-01T00:00:00.000Z再把输入改成 1704067200000，选择“毫秒”。UTC 结果应保持相同，说明两种数值表达的是同一个时刻。
| 表示方式 | 示例 |
|---|---|
| Unix 秒 | 1704067200 |
| Unix 毫秒 | 1704067200000 |
| UTC 字符串 | 2024-01-01T00:00:00.000Z |
| UTC+8 当地显示 | 2024 年 1 月 1 日 08:00:00 |
在时区选择框搜索“上海”或 Asia/Shanghai，所选时区时间应为 2024-01-01 08:00:00.000 UTC+08:00。判断固定样例是否正确时，同时核对时区标识、UTC 偏移与 UTC 字符串。
第二步：理解“相差八小时”是否真的有错
当地时间与 UTC 可以显示不同钟点，但指向同一个时刻。UTC 字符串末尾的 Z 表示 UTC；左侧另一项结果使用所选时区显示。
如果选择上海时区，本例当地钟点应为 08:00；改成其他时区后，显示会变化，左侧时间戳本身不会因此改变。不要为了让 UTC 与当地文字看起来相同，直接给时间戳加减八小时。
JavaScript 的日期以毫秒表示一个时间点，时区主要影响本地解释与显示。具体含义可参阅 MDN Date 文档。
第三步：从日期生成时间戳
先选择 Asia/Shanghai，再在右侧“日期时间”选择器设置 2024-01-01 08:00。输出的秒应为 1704067200，毫秒应为 1704067200000。
切换时区后，右侧输入的钟点保持不变，并按新时区重新生成时间戳。需要处理纽约、伦敦或其他地区的预约时，应选择目标地区的 IANA 时区，不能把“当地 08:00”当成全球唯一时刻。
例如选择 America/New_York，输入 2024-11-03 01:30，会出现两次候选时间，分别对应 UTC-04:00 和 UTC-05:00，选择后才会生成结果。输入 2024-03-10 02:30 则会提示该时间不存在，需要重新选择。UTC 偏移按输入日期计算，不能把纽约全年当成固定的 UTC-5。
日期选择器的输入精度到分钟。排查毫秒级事件时，应使用左侧时间戳结果或保留接口原始字符串，不要期待右侧选择器保留原始毫秒。
为什么错误单位会让结果落在 1970 年？
把十位秒值 1704067200 当作毫秒，会被解释为距离起点只有约二十天的时刻；把十三位毫秒值当作秒，则可能得到很远的未来日期。
“十位通常是秒、十三位通常是毫秒”只是当代日期的实用线索。历史日期、负数时间戳和未来时间不一定符合这个长度，应以接口文档中的单位为准。
对照日志前再检查三个细节
| 细节 | 检查方法 |
|---|---|
| 时间字段类型 | 确认是 Unix 数值、ISO 字符串，还是本地文字 |
| 秒与毫秒 | 明确是否已乘过或除过 1000，避免重复换算 |
| 业务发生时间 | 区分事件时间、服务器接收时间和写入数据库时间 |
只有同一事件、同一单位、同一显示时区的时间，才适合直接比较钟点。跨机器排查时还应考虑机器时钟是否同步；这个转换工具不负责校准服务器时钟。
最后把结果转回去
用本例先确认单位选择正确，再换成真实日志值，记录原始输入、单位与 UTC 输出。接收方要求整数秒时，不要把毫秒结果直接写入。
需要做“两个日期相差多久”的任务，可使用 日期计算。需要整理接口记录，可先用 JSON 格式化 查看时间字段，再逐一核对；格式化不会自动修正业务时区。