Unix 时间戳转换指南：10 位、13 位与时区问题一次讲清
Unix 时间戳怎么转日期？本文讲清 10 位秒级与 13 位毫秒级时间戳的区别，演示时间戳和本地日期双向转换，并排查时区差 8 小时、单位选错与日期格式无效等常见问题，适合接口联调和日志排错。
接口返回 1640995200，它是哪一天？日志里出现 1640995200000，为什么多了三位？把结果转成日期后又比预期多了 8 小时，究竟是数据错了，还是时区没对上？这几个问题都指向同一件事：时间戳转换。本文用固定示例讲清 10 位与 13 位时间戳的区别，并演示如何在日期、秒级时间戳和毫秒级时间戳之间转换。
如果你只想马上得到结果，可以直接打开时间戳转换工具；如果还想知道结果为什么会这样，继续往下看。
Unix 时间戳是什么
Unix 时间戳用一个数字表示某个确定时刻。它以 1970-01-01 00:00:00 UTC 为起点，常见形式是从这个起点累计的秒数。POSIX 将其称为“自 Epoch 起的秒数”，并约定每天按 86400 秒计算；浏览器里的 JavaScript Date 则以毫秒保存同一类时间值。定义可以分别参考 POSIX Seconds Since the Epoch 和 ECMAScript Date Objects。
时间戳的好处是便于排序、比较和跨系统传递。一个数字不需要携带“2026 年 8 月 1 日上午 9 点”这种本地化写法，接收方拿到后再按所需时区显示即可。
这里有个最容易混淆的点：时间戳表示时刻，日期字符串表示这个时刻在某个时区里的钟表读数。 同一个时刻，在上海和伦敦看到的日期时间可能不同，但底层时间戳不变。
10 位和 13 位时间戳有什么区别
现阶段最常见的两种 Unix 时间戳只差一个单位：
| 类型 | 常见位数 | 单位 | 示例 | 对应 UTC 时间 |
|---|---|---|---|---|
| 秒级时间戳 | 10 位 | 秒 | 1640995200 | 2022-01-01 00:00:00 |
| 毫秒级时间戳 | 13 位 | 毫秒 | 1640995200000 | 2022-01-01 00:00:00 |
两者相差 1000 倍：
毫秒时间戳 = 秒时间戳 × 1000
秒时间戳 = floor(毫秒时间戳 ÷ 1000)
JavaScript 的 Date.getTime() 返回自 Epoch 起的毫秒数；想得到秒级时间戳，通常再除以 1000 并向下取整。MDN 的 JavaScript Date 文档 也给出了同样的转换方式。
位数只是实用判断，不是永远可靠的格式规范。处理历史日期、极远未来日期或带小数的值时，不能只数位数，最好结合接口文档确认单位。鸭鸭工具让你明确选择“秒（10 位）”或“毫秒（13 位）”，目的就是避免默默猜错。
时间戳转日期：三步得到可读时间
用在线时间戳转换工具处理接口或日志里的数字，只需要三步：
- 把时间戳粘贴到“时间戳 → 日期时间”输入框。
- 选择秒级或毫秒级。
- 查看按当前设备本地时区显示的转换结果。
例如输入 1640995200 并选择秒级：
- 在 UTC 时区，它表示
2022-01-01 00:00:00。 - 在中国标准时间（UTC+8），它显示为
2022-01-01 08:00:00。
这不是多算了 8 小时。两个日期字符串描述的是同一个时刻，只是展示时区不同。排查接口问题时，先确认后端返回的是 UTC 时刻还是已经格式化的本地时间，再比较数据。
工具顶部还会实时显示当前日期、10 位秒级时间戳和 13 位毫秒级时间戳。点“使用当前时间”即可把当前秒级值带入转换区，适合快速确认系统时钟或构造测试数据。
日期转时间戳：本地时间如何参与计算
反向转换时，可以使用日期时间选择器，也可以手动输入 YYYY-MM-DD HH:mm:ss。工具会同时给出秒级和毫秒级结果，并提供复制按钮。
假设设备时区是 Asia/Shanghai，输入：
2026-08-01 09:00:00
对应结果是：
秒级：1785546000
毫秒级：1785546000000
UTC：2026-08-01 01:00:00
这里的 09:00 是本地钟表时间。HTML 的 datetime-local 控件本身不携带时区信息，浏览器根据本地环境解释它；MDN 对 datetime-local 的说明也明确指出，这类输入表示本地日期和时间，而不是带时区的绝对时刻。
如果手动输入后提示日期无效，优先改用页面上的日期时间选择器。不同浏览器对非标准日期字符串的解析可能存在差异，而选择器会提供结构更稳定的本地日期时间值。
为什么时间戳转换会差 8 小时
“差 8 小时”通常不是时间戳计算错误，而是把 UTC 和 UTC+8 当成了同一个显示时区。
情况一：UTC 被当成本地时间
后端给出 2022-01-01T00:00:00Z，其中 Z 表示 UTC。浏览器在中国标准时间下显示时，会转换为当天 08:00。
情况二：无时区日期被当成 UTC
字符串 2022-01-01 08:00:00 没有说明时区。如果一端按上海本地时间理解，另一端却按 UTC 理解，转换后就会产生 8 小时偏差。
情况三：存储和展示混在一起
数据库里保存统一时间戳，前端按用户时区展示，这是常见做法。问题往往出在展示后的本地日期又被当作 UTC 写回。排查时把链路拆开：原始时间戳、UTC 表示、本地表示分别记录，不要只盯着最终页面上的一个字符串。
接口联调和日志排错怎么用
时间戳转换最实用的场景不是背定义，而是快速判断一条数据是否合理。
检查接口字段
先用 JSON 格式化工具展开响应，再把 created_at、expires_at 或 updated_at 的数字复制到时间戳工具。如果不确定 JSON 报错位置，可以配合阅读用 JSON 格式化工具排查接口问题。
建议依次确认：
- 字段单位是秒还是毫秒；
- 时间是否落在合理日期范围；
- 过期时间是否晚于创建时间；
- 后端文档约定的是 UTC 还是业务时区。
检查定时任务
时间戳适合确认“某个时刻”，cron 表达式适合描述“按什么规律重复执行”。如果你在排查计划任务，可以先用crontab 执行时间工具列出后续运行时间，再把关键时刻与日志中的时间戳互相核对。
检查编码后的数据
有些 Token 或接口载荷会先经过 Base64 表示。先按Base64 编码解码指南还原文本，再检查其中的时间字段，比直接对着一长串字符猜更快。
常见错误与排查顺序
| 现象 | 常见原因 | 处理方法 |
|---|---|---|
| 转换结果落在 1970 年附近 | 把毫秒值误当成秒值，或输入接近 0 | 确认接口单位和原始值 |
| 日期远超预期 | 把秒值误当成毫秒值以外的单位，或数据本身异常 | 对照 10 位/13 位并查接口文档 |
| 固定相差 8 小时 | UTC 与 UTC+8 混用 | 同时记录 UTC 和本地显示结果 |
| 手动日期无法解析 | 输入格式或浏览器解析不兼容 | 使用日期时间选择器 |
| 前后端结果相差 1000 倍 | 一端用秒，一端用毫秒 | 在字段名或接口文档中明确单位 |
一个稳妥的排查顺序是：先看单位，再看时区，最后看日期字符串格式。 不要一上来就手动加减 8 小时。那可能暂时让一个样例“看起来正确”，却会把真正的时区约定藏起来。
常见问题
Unix 时间戳本身包含时区吗？
不包含。时间戳表示一个统一时刻，时区只影响这个时刻转换成日期时间后的显示结果。
10 位时间戳一定是秒，13 位一定是毫秒吗？
对当前常见业务日期通常如此，但位数只是经验判断。可靠做法仍是查看接口文档或字段约定。
时间戳转换会把数据上传到服务器吗？
不会。鸭鸭工具的日期解析和时间戳计算都在当前浏览器完成，输入内容不会因为转换操作上传。
秒级时间戳为什么要向下取整？
毫秒除以 1000 后可能有小数。向下取整表示只保留已经完整经过的秒数，也与 Math.floor(Date.now() / 1000) 的常见写法一致。
现在转换一个真实样例
拿一条真实接口响应或日志，先保留原始值，再打开时间戳转换工具分别尝试秒级和毫秒级。只要单位与时区约定明确，时间戳并不难读；真正容易出错的，是系统之间没有把这两个约定说清楚。