速查在线工具箱时间戳转换出来的时间，为什么整整差 8 小时？
差 8 小时不是时间戳错了，而是它在 UTC 与东八区之间被少换了一次。
时间戳记的是「距离 1970-01-01 00:00:00 UTC 过了多少秒」，它不带时区。当你看到本地时间与结果相差 8 小时，说明这个数字被当成 UTC 显示了一次、又被当成北京时间解释了一次——多数情况是少加了一次 8 小时。
判断口径时先数位数：秒级是 10 位，毫秒级是 13 位。把毫秒当秒会显示成 1970 年附近，把秒当毫秒会显示成五万多年以后，这两种偏差动辄上万年，与 8 小时完全不是一回事，能一眼区分。
时间戳之所以被广泛使用，正是因为它消掉了时区。它是一个绝对时刻，地球任何角落读到的都是同一个数。也正因为如此，任何「显示成本地时间」的动作都是一次额外的换算，而这步最容易漏。
漏在哪一端，决定了结果偏正还是偏负：如果服务端已经给了你北京时间字符串，而你又按 UTC 解析了一次，就会多减 8 小时；反过来，把 UTC 数字直接当北京时间读，就会少加 8 小时。
1同一个时刻，四种读法
下面这一行数字是同一个绝对时刻，差别只在「按什么口径解释」。
| 表示形式 | 数值 | 说明 |
|---|---|---|
| 时间戳（秒） | 1760000000 | 10 位，POSIX 标准与多数数据库采用 |
| 时间戳（毫秒） | 1760000000000 | 13 位，JavaScript 与不少接口采用 |
| UTC 时间 | 2026-10-08 00:00:00Z | 时间戳对应的零时区表示 |
| 北京时间 | 2026-10-08 08:00:00 | UTC 加 8 小时后的本地表示 |
把毫秒值当秒读，得到的是 1970 年 1 月附近；把秒值当毫秒读，得到的是约 5.6 万年之后。这两种偏差的量级与 8 小时完全不同，一眼就能排除。
28 小时是从哪一步漏掉的
三种典型场景，症状各不相同，但对症下药很快能定位。
- 接口返回 UTC，前端直接显示
- 少了加 8 小时这一步，显示时间比实际早 8 小时；应在格式化阶段转换为东八区
- 接口已返回本地时间，又被按 UTC 解析
- 多重减了 8 小时，显示比实际晚 8 小时；应先确认接口口径再决定要不要转换
- 数据库存了本地时间当时间戳
- 写入时把北京时间直接当 UTC 存，取出来再转一次就成了 16 小时偏差；根源在写入端
- 服务端与浏览器时区不一致
- 同一段代码在本地开发正常、上服务器后跑偏，因为两端默认时区不同；统一按 UTC 计算即可
一条好用的纪律：在系统内部一律用 UTC（或时间戳）传递与存储，只在最后一步、也就是给用户看的时候才转换成东八区。这样任何一处漏转换都能立刻暴露，不会藏进数据库。
3换算时要注意的边界
除了时区与单位，时间戳还有几个与取值相关的边界，处理老数据时会碰到。
| 情况 | 表现 | 处理方式 |
|---|---|---|
| 1970 年之前的时刻 | 时间戳为负数 | 支持负数的时间戳是合法的，表示为纪元之前；个别老旧库不支持 |
| 2038 年之后 | 32 位存储溢出 | 32 位有符号整数上限对应 2038-01-19，改用 64 位存储即可 |
| 秒级与毫秒级混用 | 同一字段两种精度 | 入库前统一精度，并在字段说明里写清单位 |
| 跨夏令时地区的时间戳 | 时间戳本身不受影响 | 夏令时只影响显示，不影响存储的绝对时刻 |
相关疑问
时间戳到底有没有时区？
没有。它是自纪元起经过的秒数，本身是绝对时刻。你说的「时间戳对应几点」一定是相对某个时区而言的，离开时区就无从换算。
为什么有的时间戳是 13 位？
13 位是毫秒精度。JavaScript 的时间函数与不少 Web 接口返回毫秒，而 POSIX 标准、数据库与令牌字段（如签发时间、过期时间）多用秒。两者相差 1000 倍，混用会得到相差近千年的时间。
时间戳能表示 2038 年以后吗？
能，只要用 64 位整数存储。出现 2038 问题的是把时间戳塞进 32 位有符号整数的老系统，其上限对应 2038 年 1 月 19 日，再往后会溢出成负数。
负数时间戳是什么意思？
表示 1970 年 1 月 1 日之前的时刻。例如负一天的数值对应 1969 年 12 月 31 日。处理历史日期时要注意，个别早期实现不支持负数。
继续看：相关问题与资料
全部问题解答 →内容说明：本页针对具体使用问题作答，方法步骤与数值由本站自行整理与复算，事实性内容以对应官方规范与文档为准。内容最后核对日期：2026-10-08。若发现错误，欢迎通过页脚反馈入口告知。