Unix 时间戳常用于接口、数据库、日志、缓存和任务调度。转换时最常见的问题是秒级和毫秒级混淆,以及 UTC 与本地时区理解不一致。
输入秒级或毫秒级时间戳,转换为可读日期,并核对时区。
常见 10 位是秒级,13 位是毫秒级。不同系统也可能使用其他精度,需结合文档确认。
通常是 UTC 与北京时间或本地时区的展示差异,不一定是时间戳本身错误。
很多系统会统一存 UTC 或时间戳,再按用户所在时区展示。具体规则应由业务系统确定。
Unix 时间戳转换最容易出错的地方是秒级与毫秒级混用,以及 UTC 与本地时区混用。排查日志、接口和数据库时间时,应同时记录原始值、单位和时区。
时间戳问题通常不是转换公式错误,而是单位和时区被混用。10 位数字多为秒级时间戳,13 位数字多为毫秒级时间戳,16 位可能是微秒级,19 位可能是纳秒级。JavaScript 的 Date 通常使用毫秒;很多后端日志、数据库和 API 则使用秒。单位错一档,时间会偏到 1970 年或远未来。
秒级:1717203600
毫秒级:1717203600000
同一时间只是在单位上相差 1000 倍。
把秒级值直接传给 JavaScript new Date() 会被当作毫秒处理,得到接近 1970 年的时间。反过来,把毫秒级值当作秒传给后端,也会得到异常未来日期。
| 长度 | 常见单位 | 检查动作 |
|---|---|---|
| 10 位 | 秒 | 转换前乘以 1000 再给 JavaScript Date。 |
| 13 位 | 毫秒 | 直接用于浏览器 Date;给秒级 API 前除以 1000。 |
| 16/19 位 | 微秒/纳秒 | 先确认来源系统,不要直接粘贴到普通转换器。 |
“差 8 小时”或“差 9 小时”通常是 UTC 与本地时区展示差异,不一定是数据错误。真正需要关注的是同一时间在多个系统里是否表示同一个瞬间。用户所在时区、服务器部署区域和业务结算时区可能不同,不能只看页面显示。
浏览器时间处理可参考 MDN Date.prototype.getTime()。涉及账单、交易、合同生效和日志取证时,应以系统记录的原始时间戳、时区字段和后端审计日志为准。
以下专题把本指南中的常见问题拆成更小的可复现案例,适合在复制、发布或提交 issue 前逐项核对。
本页的排查建议结合浏览器行为、公开标准和常见开发实践整理。涉及线上发布、安全决策或兼容性判断时,请以官方规范和你自己的运行环境为准。
本页由 Ymir Tool editorial review 维护,最后更新于 2026-06-01。页面示例使用合成输入,避免展示真实密钥、客户资料或生产日志。复制结果到正式流程前,请结合对应工具页、官方规范和你自己的运行环境再次确认。