Unix 时间戳秒与毫秒区别

这个页面解决什么问题

时间戳错误最常见的根因是单位错位。10 位通常是秒，13 位通常是毫秒，16 位可能是微秒，19 位可能是纳秒。JavaScript Date 使用毫秒，而很多 Unix API 使用秒。单位错一档会让时间落到 1970 年或异常未来。

这个页面适合排查日志时间、广告转化时间、订单创建时间、缓存过期、签名有效期和数据库时间字段。

快速判断

• 10 位数字直接传给 JavaScript Date，通常会显示 1970 年附近。
• 13 位数字传给秒级 API，通常会显示远未来。
• 同一事件差 1000 倍，优先怀疑秒/毫秒混用。
• 16 或 19 位要回到来源系统确认单位，不能直接猜。

可复制示例：错误输入与修复后输入

下面两个值表示同一个瞬间，只是单位不同。

new Date(1717203600) // treated as milliseconds

new Date(1717203600 * 1000) // seconds converted to milliseconds

JavaScript Date 构造函数接收毫秒。秒级时间戳进入 JavaScript 前应乘以 1000。

诊断步骤

1. 数位数，初步判断秒、毫秒、微秒或纳秒。
2. 用 Unix 时间工具 同时转换 UTC 和本地时间。
3. 查看字段名是否带 ms、millis、epochSecond 等单位提示。
4. 对比同一事件在前端、后端、数据库和日志中的值。
5. 在代码中用变量名写清单位，例如 createdAtMs 或 expiresAtSec。

时间戳单位属于数据契约，应写进接口文档和变量名。不要只靠开发者“记得这个字段是秒”。

常见错误表

常见误判

• 只看转换后日期，不看原始位数。
• 把本地时区差异误认为单位错误。
• 在 JSON 中混用 sec 和 ms 字段。
• 把毫秒时间戳截断成字符串再计算。

时间戳问题应先定单位，再定时区。顺序反了会把 1000 倍错误误判为时区偏移。

隐私、安全和适用边界

用于排查时请使用脱敏样本。不要粘贴访问令牌、Cookie、客户资料、内部域名、未公开商业规则、支付记录或完整生产日志。页面适合处理公开示例、教学片段、复现样本和已经替换真实值的配置。

涉及账单、交易、合规和审计时，以系统原始日志、数据库记录和业务时区定义为准。

复制或发布前复核清单

1. 位数是否记录。
2. 字段单位是否写清。
3. JavaScript Date 是否收到毫秒。
4. API 是否要求秒。
5. 是否同时查看 UTC 和本地时间。
6. 是否保留原始时间戳。

相关工具和延伸阅读

参考依据

• MDN Date.prototype.getTime()：毫秒时间值。
• Unix time 通常以秒表示。

编辑记录：Ymir Tool editorial review，2026-06-01。本页作为 Sprint 3 新增案例/排错内容发布，目标是把单一工具入口扩展为可复核的任务说明、错误示例和操作边界。