时间戳转换

什么是 Unix 时间戳？#

Unix 时间戳是从 1970 年 1 月 1 日 00:00:00 UTC（所谓的 Unix 纪元）开始累计的秒数。它是日志、数据库、API 和文件元数据里通用的”世界语”——一个不带时区、不带语言、不受夏令时干扰的纯整数。1700000000 在东京、伦敦、利马指的是同一个瞬间；而一个”2023-11-14 14:13:20”的字符串，在你没说清这是谁的钟、偏移多少之前，谁也不知道它到底指哪一刻。

麻烦在于现实里并存着两种计数习惯。经典 Unix 时间按秒算（今天仍是 10 位，如 1700000000）；而 JavaScript 的 Date、Java 的 System.currentTimeMillis() 以及大多数前端代码按毫秒算（13 位，如 1700000000000）。两者一旦搞混，你的”5 分钟前”就会变成”5000 分钟前”。本页会根据你粘贴的数值大小自动判断是秒还是毫秒，并把这一瞬间所有常见的表达形式一次性列出来，方便你直接复制下游系统需要的那种。

怎么用#

1. 在 Input 输入框里键入或粘贴一个值。可以粘贴纯数字（秒或毫秒，工具按数量级自动判断），也可以贴人类可读的日期串，比如 2026-07-26T12:00:00Z。占位提示里同时给出了两种写法。
2. 输入框下方有三个按钮按需使用：now() 会把当前瞬间按毫秒填入；Sample 载入一个参考值；Clear 清空。
3. 在右侧结果面板里读数。每一行都是同一瞬间的某一种规范形式：ISO 8601（API 期望的带 Z 后缀的 UTC 串）、Seconds（Unix 秒）、Millis（JS 风格的毫秒）、UTC（人类可读的 UTC 表述）、Local（按你浏览器所在时区渲染的本地时间）。

核心特性#

• 按数量级判断秒/毫秒。 任何小于 10,000,000,000 的数值按秒读；超过则按毫秒读。这条分界线对秒来说落在 2286 年、对毫秒来说落在 1970 年初，所以现实里任何合理的当下时间戳都能被正确分类，不需要额外的单选框。
• 数字与日期串都吃。 1700000000、1700000000000、ISO/HTTP 风格的日期都能解析；串不是合法日期时会给出清晰的错误。
• 五种输出同时呈现。 ISO 8601、Unix 秒、Unix 毫秒、UTC 文字、本地文字——一次给你数据库、日志或前端各自需要的那种表示，省去手工换算。
• 100% 在浏览器本地计算。 不向任何地方发送数据，转换无非是浏览器里的 Date 算术。

实例演示#

粘贴 1700000000（一个规整的 10 位值——显然是秒）。面板把这一瞬间解析为：

ISO 8601:  2023-11-14T22:13:20.000Z
Seconds:   1700000000
Millis:    1700000000000
UTC:       2023 年 11 月 14 日 下午 10:13:20 UTC
Local:     （按你自己的时区渲染）

再粘贴 1700000000000（多三个零——毫秒）。由于这个值超过了 1e10 的阈值，它被读作毫秒，解析出的仍是同一瞬间——面板完全一致。这正是数量级规则的全部意义：同一个时刻，无论用哪种习惯书写，都解码出唯一一个无歧义的答案。

常见问题#

工具是怎么判断秒还是毫秒的？#

看数值大小。1700000000 这种 10 位值小于 100 亿，按秒处理；1700000000000 这种 13 位值超过这条线，按毫秒处理。这条线之所以安全，是因为 100 亿秒落在 2286 年，而 100 亿毫秒落在 1970 年初——没有任何现实时间戳会落在那个模糊地带里。

为什么我的本地时间和别人的不一样？#

Local 行是按你操作系统设置的时区渲染的；UTC 行则是绝对的。两个人粘贴同一个时间戳，看到的 UTC 和 ISO 行完全相同，但 Local 行不同——这才是对的，因为瞬间相同，只是墙上的钟不同。

后端给我的时间戳是 13 位，是坏了吗？#

没坏，只是毫秒。很多运行时（JavaScript、Java、部分 Python 库）默认就是毫秒精度。原样粘进输入框即可；工具会按数量级识别，并在 Seconds 行里给出对应的 10 位秒值，供那些期望经典 Unix 时间的系统使用。