Unix 时间戳完全指南：秒与毫秒、时区与联调

更新 2026-08-08 约 12 分钟时间工具 How-to

日志里一串 1713171485、接口字段 createdAt: 1713171485000、或 JWT 里的 exp，都在问同一件事：这是哪个时刻、用的是秒还是毫秒、显示时有没有时区错位。本指南讲清 Epoch 约定、单位判断、WebUtils 操作步骤与联调场景，并说明和 JWT 过期字段的关系。

立即使用相关工具 时间戳转换 — 秒/毫秒互转，本地与 UTC 对照

打开工具 →

核心一句话

Unix 时间戳是「自 1970-01-01 00:00:00 UTC 起的流逝量」；位数与单位搞反，日期会错出几十年，时区只影响「怎么显示」，不改变同一瞬间的绝对时间。

可直接在 Unix 时间戳转换上对照：实时当前戳、戳→日期、日期→戳。

1. Epoch 到底在计什么

Unix 时间戳（Epoch）通常表示从 UTC 纪元起经过的秒数（或毫秒数），不考虑闰秒的日常工程约定。它适合排序、存库、跨语言传递；不适合直接给人念「礼拜几几点」——那是格式化与时区的事。

概念	含义	常见误解
时间戳数值	绝对瞬间的度量	以为「数字里自带北京时间」
本地显示	用某时区规则格式化同一瞬间	改显示等于改了戳
UTC 显示	零时区日历时间	和「没有时区」不是一回事
ISO 8601	带偏移或 `Z` 的标准文本	和纯数字戳可互转但形态不同

页面顶部「现在时刻」用 Date.now() 展示毫秒级当前戳，并显示本机时区名与 UTC 偏移，方便确认你电脑认为「现在」是什么。

2. 秒与毫秒：位数不是玄学

形态	典型位数	单位	常见来源
10 位左右	~10	秒	许多后端、PHP、Python `time.time()` 取整、JWT `exp`/`iat`
13 位左右	~13	毫秒	JavaScript `Date.now()`、部分 Java、前端埋点
16 位等	更长	微秒/纳秒（少见）	特定数据库/系统，本工具按秒/毫秒选择处理

经验法则：

看数量级：2020 年代的秒戳大约在 1.6e9～2e9；毫秒大约在 1.6e12～2e12。
把秒当毫秒：new Date(1713171485) 会落在 1970 年附近（毫秒视角下太小）。
把毫秒当秒：日期会飞到远未来，相对时间显示成「将来 N 天」。

本工具「时间戳转日期」提供单位下拉：秒 (s) / 毫秒 (ms)（默认毫秒）。不会仅凭位数自动改你选的单位——以你下拉选择为准；位数只是你自己判断的线索。点「当前」会填入现在的毫秒戳并设单位为 ms。

3. 时区：同一瞬间，两套日历读数

转换成功后，结果表给出：

行	含义	何时盯它
北京时间 (Local)	浏览器本地时区格式化（`toLocaleString`）	和你本机日历、聊天记录对齐
UTC 时间	强制 `timeZone: "UTC"` 的读数	和服务器日志、跨区同事对齐
ISO 8601	`toISOString()`，一般以 `Z` 结尾	写进 API、配置、跨语言
相对时间	距现在的粗粒度描述	快速判断「刚发生 / 很久以前 / 将来」

注意： 标签写「北京时间 (Local)」时，若你系统时区不是东八区，实际是本机本地，不是强行 Asia/Shanghai。跨时区排错请同时看 UTC 与 ISO。

日期→时间戳使用 datetime-local，按浏览器本地时区解释你选的墙钟时间，再输出秒与毫秒两个结果。在「我想要东八区某时刻」但电脑设在美国时区时，会对不齐——先改系统时区或心算偏移，或只用 UTC/ISO 沟通。

4. 和 JWT `exp` 的一点关联

JWT 注册声明里的 exp、iat、nbf 在规范上是 NumericDate，单位为秒。联调 401「过期」时：

用 JWT 解码器读出 exp 数值与工具给出的本地提示。
把同一数字贴进时间戳工具，单位选秒，核对 UTC/本地是否已过。
切勿把 exp 当毫秒解析，否则会误判「还早得很」。

时间戳工具不负责验签；它只帮你把「数字 ↔ 可读时间」算清楚。

5. 逐步操作

A. 时间戳 → 日期

打开 /tools/time/timestamp。
在「时间戳转日期」输入框粘贴数字（可先点顶部当前戳复制练习）。
在单位下拉选择秒或毫秒（与数据来源一致）。
点转换。成功则显示结果表；失败看状态行「请输入时间戳 / 格式错误 / 无效的时间范围」。
需要时点各行旁复制，或点当前填入现在毫秒戳。

B. 日期 → 时间戳

在「日期转时间戳」用日期时间控件选时刻（可点当前重置为现在）。
点转换，读取 秒 (10 位) 与 毫秒 (13 位) 两行。
写入 API 或 SQL 时确认对端要的是秒还是毫秒。

能力边界

支持： 实时毫秒戳、秒/毫秒互转展示、本地与 UTC、ISO、相对时间、日期控件反算。
不替代： 完整 IANA 时区选择器、闰秒级天文时间、服务端权威 NTP。
同站另有 /tools/converter/unix-timestamp 等入口时，以本篇主工具路径为准练习即可；概念通用。

6. 常见错误对照

现象	常见原因	处理
结果落在 1970 年	秒戳却按毫秒解析，或少了几个数量级	单位改「秒」；核对位数
结果在远未来	毫秒按秒解析	单位改「毫秒」
和服务器差 8 小时	只比了本地字符串，没看 UTC	统一用 UTC 或 ISO 对比
和数据库差一截	库会话时区、`TIMESTAMP` vs `TIMESTAMPTZ`	查库类型与会话 `time_zone`
状态「格式错误」	粘贴了非数字、逗号、单位后缀	只留整数数字
「无效的时间范围」	数值溢出或非法	检查是否多粘了一位、是否科学计数法
相对显示「将来」	戳大于现在（或单位放大）	核对单位与时钟
JWT 未过期却 401	不止时间问题：`aud`/签名/网关	解码 JWT 全声明，时间只是一层
日期控件结果「不对」	本机时区与业务时区不同	用 UTC 沟通或校准系统时区
前端 JS 与后端差 1000 倍	一端秒一端毫秒	在契约里写死单位并加示例

7. 真实工作场景

场景 A：接口字段到底过没过期

响应里 expireAt: 1735689600。单位选秒转换，看 UTC 是否已过。若产品文案写「北京时间 2025-01-01 0 点」，用本地行与产品确认是否按东八区解释。

场景 B：SQL 条件怎么写

产品说「统计昨天东八区全天」。先算出起止墙钟，转成秒或毫秒（与列类型一致），再写 WHERE created_at >= ? AND created_at < ?。避免在 SQL 里混用字符串日期与戳却不统一时区。

场景 C：日志对齐事故窗口

多台机器日志有的打 ISO，有的打 Epoch。全部转到 UTC 再排序，才能发现「其实是同一分钟的级联失败」。

场景 D：前端 `Date` 与后端秒

Node/浏览器习惯毫秒；不少 Go/Java 接口用秒。联调清单写死示例：同一瞬间的秒与毫秒各一列，贴进本工具交叉验证。

场景 E：JWT 登录态「明天才过期」却失败

解码 exp 为秒，用本工具确认；若时间无误，转向签名、nbf、网关时钟。参见 JWT 解码指南（若已发布）或工具页。

场景 F：导出报表给运营

不要只给裸戳。导出 ISO 或明确标注时区的本地时间；需要程序再处理时另附 Epoch 列并注明单位。

9. 协作与契约建议

API 文档每个时间字段写明：unix seconds 或 unix milliseconds，并给一例。
禁止同一资源混用两种单位却同名 timestamp。
监控告警用 UTC；给人类的邮件再用本地格式化。
容器镜像确保 NTP；否则「偶发 Token 过期」会变成排障黑洞。
测试夹具固定一两个瞬间（如 1700000000），全链路断言可读时间。

常见问题

为什么我电脑上「本地」不是北京时间？

工具按浏览器时区格式化。系统时区在东京或洛杉矶时，本地行就不是东八区。跨地区协作请报 UTC 或 ISO。

10 位和 13 位哪个「标准」？

都是常见工程实践。JWT 与许多后端偏秒；JS 偏毫秒。标准的是 约定单位，不是位数迷信。

相对时间「刚才」准吗？

它是粗粒度提示，不是审计依据。精确对比用 ISO 或同时复制秒与毫秒。

2038 问题还要关心吗？

32 位有符号秒会在 2038 溢出；现代系统多用 64 位。选存储类型时仍避免「秒用 32 位有符号」的老库表设计。本工具在 JS Date 安全范围内工作，极端远古/远未来可能显示异常。

日期转戳是否含夏令时？

datetime-local 按运行环境规则解释。跨越夏令时切换日时，优先用 UTC 固定瞬间再分发。

能否批量转换 CSV？

本页面向单值交互。批量请用脚本，但可用本页抽查边界值是否与脚本一致。

在线转换会上传我的时间吗？

计算在浏览器本地完成。时间戳本身敏感度通常低于密码，但若与订单号等拼在同一调试串，仍注意脱敏。

和「北京时间戳」网站结果差一秒？

刷新时刻不同、或一端四舍五入到秒。对比时固定同一输入数字，并统一单位。

继续浏览

复制页顶当前毫秒戳，切换秒/毫秒各转一次，体会数量级差异；再拿一枚测试 JWT 的 exp（秒）走一遍。

打开时间戳工具打开 JWT 解码返回指南列表全部工具