Unix 时间戳是什么？怎么转换成日期时间

一串看不出含义的数字

1735689600 是一个合法的时间，1735689600000 也是。两者含义相差 1000 倍，肉眼看不出区别——这正是最容易踩的第一个坑。

它们都是 Unix 时间戳：从 1970-01-01T00:00:00Z（纪元时间）起经过的时间。数据库存它、接口返回它、日志里全是它，但人脑读不了它。

知道规则就很简单：

位数	单位	大致对应
10 位	秒	2001 → 2286 年
13 位	毫秒	同样日期，数值 ×1000

JavaScript 的 Date.now() 返回毫秒，而多数后端语言和 Unix 命令返回秒。这个不匹配是经典 bug：毫秒值除以 1000 会得到 1970 年附近的日期，秒值当成毫秒用同样会落到 1970 年。

Unix 时间戳转换工具会自动识别位数，两种都显示。

时间戳本身没有时区，它表示一个绝对时刻；是渲染方式带了时区。

所以当时间戳"显示成了前一天"，问题几乎总是：少写了 Z、缺了时区偏移，或者服务端按本地时间格式化而客户端按 UTC 理解。

转换工具会把 ISO 8601（UTC） 和 本地时间 两行并排显示，差异一眼可见。

数据库：存 UTC，按用户时区渲染。存本地时间是少数几个很难挽回的日期决策之一。

日志：请求旁边那个 10 位数字，基本都是秒级 epoch 时间。

接口：看字段名——created_at、createdAt、timestamp 常常是 epoch 值，但单位不能靠猜，看位数。

JavaScript 里：

// 秒 → Date
new Date(1735689600 * 1000)

// 毫秒 → Date
new Date(1735689600000)

// Date → 秒
Math.floor(Date.now() / 1000)

单位混用：乘除 1000 只能做一次，多数 bug 是重复转换导致的。
误以为解析成本地时间：new Date('2026-01-01') 按 UTC 解析，而 new Date('2026-01-01 00:00:00')（带空格）在多数引擎里按本地时间解析。
闰秒：Unix 时间本身就忽略闰秒，不要自作聪明去补。
2038 问题：32 位有符号时间戳将在 2038-01-19 溢出，用 64 位或毫秒可以避开。
负值：合法，表示 1970 年之前的日期。

偶尔验证一次，浏览器控制台就够了。但如果是反复的活——调接口、把日志时间对应用户反馈、写测试——一个能同时给出秒、毫秒、UTC、本地时间、星期和相对时间的工具会省下大量时间。试试时间戳转换工具，它在本地运行，离线也能用。

时间戳带时区吗？ 不带。它表示一个绝对时刻，时区只在你格式化它的时候才出现。

为什么我转换出来是 1970 年？ 基本可以确定是单位问题：把秒当成毫秒用了，或者反过来。

ISO 8601 字符串呢？ 那是人类可读的替代方案（如 2026-01-01T00:00:00Z）。自己设计接口时推荐用它，消费别人的接口时两种都要能接受。

时间戳可以是负数吗？ 可以，表示 1970 年之前的日期。