日期时间
给人看的结果，按所选时区显示，精确到秒。排查日志、填写表单时用它。
TIME WORKBENCH / FULL VIEW
在线时间戳转换工作台
这一页把时间戳、日期、时区和常用格式放在同一个视图里。无论你手上是 10 位秒级数字，还是从接口日志里复制出来的 13 位毫秒值，都可以先在这里确认它究竟指向哪一刻，再决定怎么写进代码或数据库。
ONLINE CONVERTER
时间戳转换
按 1、2、3 步填写，结果会自动更新，也可以点击转换按钮确认。
当前时间戳
秒级
支持 10 位秒级、13 位毫秒级、16 位微秒和 19 位纳秒，系统会自动识别。
快速填入
选择输入单位和显示时区
切换显示时区只改变显示方式，不改变时间戳代表的绝对时间点。
输入内容后结果会自动更新；点击按钮可以立即确认当前输入。
转换结果会显示在这里在上方输入时间戳，或点击“填入当前时间”先试试看。
转换结果
—
—
——
- 秒级时间戳
- —
- 毫秒级时间戳
- —
ISO 8601
—
UTC 时间
—
时区偏移
—
这里填写的是某地的钟表时间。工具会先把它还原成 UTC 时间点，再输出秒级与毫秒级时间戳。
快速填入
选择输入时区
跨时区填写会议时间时，先确认它是哪个城市的钟表时间，再选择对应时区，能避免最常见的 8 小时误差。
转换结果会显示在这里选择日期和时间后，会同时给出秒级与毫秒级时间戳。
转换结果
—
秒级时间戳
—
—
——
- 秒级时间戳
- —
- 毫秒级时间戳
- —
ISO 8601
—
UTC 时间
—
READ THE RESULT / 读结果
结果里的每个字段，
对应一种使用方式
同一个时间点会以不同格式出现。它们不是互相矛盾的答案，而是面向不同系统的“方言”。选对字段，比记住更多格式更重要。
秒级时间戳
多数后端接口和 Unix 命令使用这一种，通常是 10 位。写接口参数时优先确认字段单位。
毫秒级时间戳
JavaScript 的 Date.now() 原生输出毫秒，通常是 13 位。前端计时与日志常见。
ISO 8601
带 T 与 Z 的标准写法，适合 API、JSON 和跨系统传输，不含歧义。
UTC 时间
排除本地时区干扰后的基准时间。对比服务器日志和海外系统时最可靠。
星期与年内天数
用于排期、报表和“第几周”的核对。ISO 周与自然周不完全相同，跨年时尤其要留意。
THREE DECISIONS / 三个判断
一次可靠的转换，
其实只多了三个判断
大多数错误并不是算错，而是单位、方向或时区选错。转换之前各停一秒，结果会稳定很多。
先判断单位
看数量级和来源字段。10 位通常是秒，13 位通常是毫秒。拿不准时，先手动锁定单位，再用一个已知时间点验证。
再判断方向
是要把数字变成日期，还是把日期写成数字？日期转时间戳时，输入的钟表时间必须先绑定一个时区，否则结果没有唯一答案。
最后判断显示
同一个时间点，北京时间、UTC 和纽约时间看起来完全不同。先把显示时区调到与业务一致，再去复制结果。
FORMAT TABLE / 格式
同一时刻的七种写法
下面以 2026-01-01 08:00:00（北京时间）为例。它们都能表示同一个瞬间，但适用场景不同，复制前先看清目标系统要哪一种。
| 格式 | 示例 | 常见用途 | 注意点 |
|---|---|---|---|
| Unix 秒 | 1767225600 | 后端接口、缓存、Unix 命令 | 10 位，不带时区 |
| Unix 毫秒 | 1767225600000 | JavaScript、移动端日志 | 13 位，是秒的 1000 倍 |
| ISO 8601（UTC） | 2026-01-01T00:00:00.000Z | JSON、API 字段 | 末尾 Z 表示 UTC |
| RFC 3339（+08:00） | 2026-01-01T08:00:00+08:00 | 跨时区接口、配置文件 | 偏移与时间必须同时正确 |
| RFC 2822 | Thu, 01 Jan 2026 00:00:00 GMT | 邮件头、部分协议 | 英文星期与月份缩写 |
| MySQL DATETIME | 2026-01-01 08:00:00 | 数据库存储与查询 | 受会话时区影响 |
| 中文可读 | 2026年1月1日 08:00:00 | 页面展示、说明文档 | 不适合机器解析 |
注意：MySQL 的 FROM_UNIXTIME() 会按当前会话时区解释结果，和浏览器里选择的时区不一定是同一个。数据库排查时，同时记录 @@session.time_zone 和 @@global.time_zone。
CHOOSE THE UNIT / 选单位
秒和毫秒，
不是“精度越高越好”
秒级时间戳更短、更容易阅读，适合不需要毫秒的业务时间，比如文章发布时间、订单创建日期。毫秒级适合前端交互、性能日志和需要排序的高频事件。
如果接口约定使用秒，却在某个环节被乘了 1000，时间会跳到几万年之后；反过来，毫秒被当成秒，则会回到 1970 年附近。这两个异常都非常显眼，也是排查时最快的线索。
微秒和纳秒更适合底层系统或高精度测量。把它们展示成日期时，浏览器最终仍会把精度落到毫秒，这一点需要在业务上提前约定，而不是依赖显示层“看起来更精确”。
一个实用的检查转换结果如果落在 1970-01-01 到 1970-01-03 之间，先怀疑“毫秒被当成了秒”；如果落在公元 5000 年以后，先怀疑“秒被当成了毫秒”。
- 接口文档里明确写
seconds还是milliseconds，不要只写“时间戳”。 - 数据库字段用
BIGINT或带时区的时间类型，避免 32 位溢出与隐式转换。 - 日志里同时记录原始值与单位，排查时不用猜。
- 跨语言传递超过 13 位的整数时，用字符串而不是 JSON Number。
- 展示层统一时区，存储层统一 UTC，是两条最省心的约定。
QUICK ANSWERS / 问答
转换时的几个具体问题
更完整的问题库在常见问题页；这里先回答与工作台直接相关的三项。
输入 13 位数字后，为什么结果看起来没问题？
因为工具会自动按毫秒解释 13 位数字。自动识别的依据是数量级，而不是单纯数字符个数。如果你确定它其实是秒，只需要把“输入单位”改成秒，结果会随之变化。
日期转时间戳时，为什么必须先选时区？
“2026-01-01 08:00:00”只是一段钟表读数，没有说明这是北京、伦敦还是纽约的早上。只有绑定一个时区，它才对应唯一的 UTC 时间点，才能算出唯一的时间戳。
结果里的 ISO 时间为什么以 Z 结尾？
Z 是 UTC 的零时区标记。工具给出的 ISO 8601 采用 UTC，避免接收方再次猜测时区。如果你需要带 +08:00 的 RFC 3339 写法，可以按结果里的日期与偏移自行拼接，或查看格式表。