Unix 时间戳是什么：秒与毫秒怎么区分、怎么换算

时间戳到底是什么

Unix 时间戳是程序世界最通用的计时方式：它只是一个数字，表示从 1970-01-01 00:00:00 UTC 这一起点开始，已经过去了多少秒（秒级时间戳）或多少毫秒（毫秒级时间戳）。这个起点是全行业统一约定的基准，与操作系统、编程语言、所在时区都无关。

一个常见的误解是「时间戳带时区」。恰恰相反：时间戳本身没有时区属性，它只是相对固定基准的偏移量。时区只在「展示」这一步才参与——同一个时间戳，按北京时间展示是一个写法，按 UTC 展示是另一个写法，但描述的是同一个瞬间。

程序世界偏爱它有三个原因：数值随时间单调递增，先后顺序就是数值大小，判断两条记录谁先谁后只需要比较数字；可以直接做减法求时间间隔，不需要先解析成日期；跨语言、跨库、跨系统的口径完全统一，数据交换不会有歧义。所以日志、接口返回、数据库字段里到处都是这种「裸数字」。

秒级与毫秒级：10 位与 13 位怎么区分

拿到一个数字，最先要回答的问题是：它是秒还是毫秒？目测数位数是最直接的线索：10 位数字基本是秒级——这个范围能覆盖到 2286 年；13 位数字则是毫秒级。

更稳的口径是看数值大小：绝对值小于 10¹² 按秒处理，否则按毫秒处理。这条线并不随意：10¹² 毫秒约合 2001 年 9 月，此后产生的毫秒时间戳都超过 10¹²，而秒级时间戳要长到 13 位，得等到三万多年以后，两者几乎没有重叠区间。1970 年以前的时间用负数表示，同样按绝对值参与判断，这套规则对负数时间戳一样适用。

当然，启发式终归是启发式：如果数值恰好落在这条线附近、换算结果看起来不对，先自行换算单位再输入即可。另外，数字也不是无限大的：JavaScript 的 Date 能表示的范围是 ±8.64×10¹⁵ 毫秒，约合正负 27 万年，超出这个范围就没有可表示的日期了。遇到这类超限输入，本站工具会提示越界，而不是抛出错误让页面不可用。

换算结果差 8 小时的三种典型原因

时间戳本身没有时区，但「换成几点几分」这一步一定落在某个时区上。用工具换算出的时间，和日志或另一个工具差了整整 8 小时——正好是东八区与 UTC 的偏移——是东八区用户最常遇到的困惑。原因几乎都落在下面三种里：

1. 工具按浏览器本地时区（东八区）展示，而日志写的是 UTC 时间——这是最常见的一种，两边各说各话。
2. 服务端时区与浏览器时区不一致，比如服务器配置成了 UTC，而你在本地按东八区去理解。
3. 比对前没有统一口径，一边按 UTC 一边按本地时区，直接拿字符串对比。

核对方法只有两步：先看工具页头标注的当前时区名，确认换算结果按哪个时区展示；再确认日志系统或服务端的时区配置。两边口径对齐后，8 小时的「误差」自然消失。

三个真实排查案例

案例一：接口返回了一个 10 位数字。 对接第三方接口，字段里只有类似 1760000000 这样的十位数字。十位数按秒处理即可，把它粘进换算工具，立刻得到具体日期，就能判断这条数据是今天产生的，还是几个月前的存量——不用猜，也不用写代码。

案例二：日志里是毫秒时间戳。 用户反馈「上午十点左右功能异常」，而服务端日志的每一行都带着 13 位毫秒时间戳。毫秒与秒差着一千倍，先统一单位再换算，把疑似时段的时间戳换成具体时刻，和用户反馈的时间点比对，就能把问题时段定位出来。

案例三：定时任务没按时触发。 怀疑 cron 任务没有执行时，先核对「下次执行时间」对应的绝对时刻，再对照相对时间（如「3 分钟前」）确认间隔是否符合预期。绝对时刻先分清配置是否正确，相对间隔再看任务到点有没有跑，两者结合最快定位问题。

在本站怎么换算

在本站的时间戳转换工具页上，页顶就是实时跳动的当前 Unix 时间戳——静态页面首屏先显示占位，页面在浏览器里跑起来后才开始实时更新。四步就能完成一次核对：

1. 页顶实时显示当前 Unix 时间戳，可在秒与毫秒之间切换单位；需要固定值时暂停刷新，再点「复制」。
2. 把待转换的数字粘进输入框，页面自动识别秒级或毫秒级，下方即时给出对应的日期时间。
3. 反向换算时在日期一侧填写日期时间，即可得到对应的时间戳，直接粘进脚本或代码。
4. 对照「相对时间」一行确认间隔是否符合预期（如「3 分钟前」）。

整个过程基于浏览器内置的 Date 对象在本地完成，输入的数字不会离开你的设备。