时间戳转换

什么是 Unix 时间戳

Unix 时间戳(也叫 epoch 时间、POSIX 时间)是从 1970 年 1 月 1 日 00:00:00 UTC 起经过的秒数 —— 这个起点只是早期 Unix 系统选的一个顺手整数。它朝后计数, 在某些系统里也可以为负数, 表示更早的时刻。

由于它是不带时区的单个整数, 也是存储时刻最通用的方式: 同一个时间戳在上海、伦敦和纽约指的是同一瞬间, 只有显示的时候才涉及时区。

秒还是毫秒?

两种在实践中都很常见, 而分不清它们正是 bug 的常见来源:

• 10 位数字 —— 秒, Linux、PHP、Python 与大多数接口都用它。`1700000000` 是 2023 年 11 月 14 日。
• 13 位数字 —— 毫秒, JavaScript 的 `Date.now()`、Java 以及多数移动端/浏览器接口用它。`1700000000000` 是同一时刻。

本工具会根据位数自动判断单位。遇到难以分辨的数值, 请手动指定单位 —— 把「秒」传给期待「毫秒」的接口会掉回 1970 年, 反之则一下子跳到五万年后。

代码里怎么转

• JavaScript: 取秒用 `Math.floor(Date.now() / 1000)`; 转回来用 `new Date(ts * 1000)`。
• Python: `time.time()` 返回浮点秒; `datetime.fromtimestamp(ts)` 转换(不指定 UTC 时按本地时区)。
• PHP: `time()` 返回秒; `date('Y-m-d H:i:s', $ts)` 格式化。
• SQL: MySQL 用 `FROM_UNIXTIME(ts)`, PostgreSQL 用 `to_timestamp(ts)`。

实用提醒与坑

• 时间戳是 UTC 的。 同一时间戳显示为上海 08:00 和 UTC 00:00, 数值完全一样 —— 存时间戳, 显示时再格式化。
• 两端单位要一致。 前后端之间最常见的事故就是把秒和毫秒搞混。
• 2038 问题。 用有符号 32 位整数存秒的系统会在 2038 年 1 月 19 日 03:14:07 UTC 溢出。迁到 64 位(或 64 位毫秒)即可解除限制; JavaScript 因为数字是 64 位浮点, 目前没有这个问题。
• 闰秒被忽略。 Unix 时间假定每天恰好 86400 秒, 因此几十年下来会与 UTC 差上约一秒。这对天文有影响, 对应用几乎无影响。
• 时长不是时间戳。 90 分钟的视频是 5400 秒, 那是「时长」而不是「某一刻」, 不要用时间戳存时长。

隐私

全部转换在浏览器本地完成, 你粘贴的日志、数据库值或内部时间戳都不会被上传。

FAQ

怎么判断时间戳是秒还是毫秒?

数位数: 10 位是秒(目前约 17 亿), 13 位是毫秒(约 1.7 万亿)。快速核对: 10 位、落在 16–18 亿区间的大致就是当下; 同一时刻的毫秒值就是它后面再加三个零。

为什么同一个时间戳显示出的时间不一样?

因为时间戳本身不含时区, 它只代表一个绝对瞬间。同一个数值是 UTC 00:00、上海 08:00、洛杉矶(前一天)16:00。想要与时区无关的答案就看 UTC 那一行; 想还原某地区用户看到的时间就看本地时间那一行。

2038 年以后会怎样?

用有符号 32 位整数存秒的系统会在 2038 年 1 月 19 日 03:14:07 UTC 溢出, 跳回 1901 年。把这些字段迁到 64 位(或像 JavaScript 与多数现代接口那样用 64 位毫秒)可把上限推到几千亿年之后。如果你维护较早的 C、PHP 或数据库代码, 建议提前排查这些字段。

Unix 时间会受闰秒影响吗?

Unix 时间刻意忽略闰秒: 它假定每天恰好 86,400 秒。几十年累积下来会与 UTC 相差约一秒。对日志、定时任务和应用数据存储来说这无关紧要; 只有依赖精确天文计时的场景才需要注意。