首页 / 指南中心 / 时间戳

Unix 时间戳转换工具使用说明

Unix 时间戳常用于接口、数据库、日志、缓存和任务调度。转换时最常见的问题是秒级和毫秒级混淆,以及 UTC 与本地时区理解不一致。

Unix 时间戳说明

输入秒级或毫秒级时间戳,转换为可读日期,并核对时区。

打开 Unix 时间戳转换工具

推荐入口

常见场景

使用建议

  1. 先判断时间戳是 10 位秒级还是 13 位毫秒级。
  2. 确认目标时间使用 UTC 还是本地时区。
  3. 跨地区业务应明确存储时间和展示时间的规则。
  4. 调试时记录原始时间戳,避免只保存转换后的文本。

常见错误

FAQ

10 位和 13 位时间戳有什么区别?

常见 10 位是秒级,13 位是毫秒级。不同系统也可能使用其他精度,需结合文档确认。

为什么转换结果差 8 小时?

通常是 UTC 与北京时间或本地时区的展示差异,不一定是时间戳本身错误。

数据库里应该存本地时间吗?

很多系统会统一存 UTC 或时间戳,再按用户所在时区展示。具体规则应由业务系统确定。

打开时间戳转换工具

时间戳常见误差

Unix 时间戳转换最容易出错的地方是秒级与毫秒级混用,以及 UTC 与本地时区混用。排查日志、接口和数据库时间时,应同时记录原始值、单位和时区。

Unix 时间戳排查先判断单位,再判断时区

时间戳问题通常不是转换公式错误,而是单位和时区被混用。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 位微秒/纳秒先确认来源系统,不要直接粘贴到普通转换器。

时区排查流程

  1. Unix 时间戳工具 先确认单位。
  2. 记录转换出的 UTC 时间和本地时间,不要只截取一个显示值。
  3. 检查日志来源时区、服务器时区、数据库时区和浏览器时区。
  4. 跨系统比较时统一转成 ISO 8601 或 UTC,再回到本地展示。

常见误判

“差 8 小时”或“差 9 小时”通常是 UTC 与本地时区展示差异,不一定是数据错误。真正需要关注的是同一时间在多个系统里是否表示同一个瞬间。用户所在时区、服务器部署区域和业务结算时区可能不同,不能只看页面显示。

参考依据

浏览器时间处理可参考 MDN Date.prototype.getTime()。涉及账单、交易、合同生效和日志取证时,应以系统记录的原始时间戳、时区字段和后端审计日志为准。

参考资料和规范来源

本页的排查建议结合浏览器行为、公开标准和常见开发实践整理。涉及线上发布、安全决策或兼容性判断时,请以官方规范和你自己的运行环境为准。

编辑与复核说明

本页由 Ymir Tool editorial review 维护,最后更新于 2026-06-01。页面示例使用合成输入,避免展示真实密钥、客户资料或生产日志。复制结果到正式流程前,请结合对应工具页、官方规范和你自己的运行环境再次确认。