Unix 时间戳怎么转换：秒、毫秒与时区实例
接口返回一个很大的整数时，常见疑问是：它表示秒还是毫秒？为什么同一个时间在服务端和浏览器显示差了 8 小时？先确认单位，再确认日期文本是否带有时区，通常就能把问题拆开。
先辨认秒和毫秒
Unix 时间戳表示从 1970-01-01T00:00:00Z 起经过的时间。不同接口可能用秒或毫秒；JavaScript 的 Date 时间戳单位是毫秒，而许多 API 示例会把时间转换成整数秒。
const milliseconds = Date.now();
const seconds = Math.floor(Date.now() / 1000);上面的两行代表相近的当前时刻，但数值相差约 1000 倍。趁手时间戳工具的“自动识别”按数值绝对值是否达到 1e12 作为毫秒判断线；这是便于常见现代日期使用的启发式，不是时间戳标准，也不能证明一个大整数一定是时间。
用一个时刻核对换算
以下三种输入指向同一瞬间：2025 年元旦的 UTC 零点。
Unix 秒： 1735689600
Unix 毫秒： 1735689600000
带偏移的日期： 2025-01-01T08:00:00+08:00结果应为 2025-01-01T00:00:00.000Z。把它显示为北京时间，则是 2025-01-01 08:00:00。换算时要把单位和时区分开：秒/毫秒决定数值比例，时区决定同一瞬间如何显示。
实际排查时，先从接口文档确认单位；如果没有文档，可把秒和毫秒两种方式都转换，再看结果年份是否合理。不要只凭“位数像 10 位或 13 位”判断，历史时间、未来时间和业务 ID 都可能不符合常见长度。
日期文本要带时区
Z 表示 UTC；数值偏移量表示当地时间与 UTC 的差值。例如 2025-01-01T08:00:00+08:00 与 2025-01-01T00:00:00Z 是同一时刻。RFC 3339 采用带 Z 或数字偏移量的互联网日期时间格式，适合日志和接口传递明确的时间点。
像 2025-01-01 08:00:00 这样的字符串没有说明时区。工具会交由浏览器日期解析；无时区的日期时间可能按本地时区解释，非标准格式也可能存在实现差异。跨系统传值时，优先使用带 Z 或 +08:00 的 ISO 8601 / RFC 3339 形式。
批量转换与时间加减
日志里有多行时间戳时，可以在时间戳工具切换到批量模式，每行放一个秒、毫秒或带时区日期。结果会分别列出秒、毫秒、ISO 时间和常用时区，便于比对数据库、应用日志与浏览器显示。
时间加减按固定时长计算。例如加一小时是加 3,600,000 毫秒；加 24 小时是加 86,400,000 毫秒。跨越夏令时切换时，“经过 24 小时”和“当地日历上的明天同一钟点”可能不同。若业务要求按当地日历日排期，应使用带时区的日历运算规则，而非固定毫秒数。
常见误区和工具边界
- 把所有 13 位整数都当时间戳：自动识别只看数量级，订单号或其他 ID 也可能有类似长度，应核实字段定义。
- 把显示时区差异当成时间不同：先比较统一为 UTC 的时间或 epoch 数值，再检查格式化时区。
- 省略日期字符串的时区：机器本地设置可能不同；面向接口和日志时写明
Z或偏移量。 - 把 24 小时等同日历上的一天：涉及夏令时的地区，两者可能不相同。
- 期待亚毫秒精度：浏览器
Date的时间值以毫秒表示，工具输出不保留更细的精度。
趁手的时间戳转换工具支持秒/毫秒、常见时区、批量输入和固定时长加减。转换在当前浏览器完成；首次打开页面仍需网络加载页面资源。
可靠参考
- MDN：Date.now()——返回自 Unix epoch 起的毫秒数。
- MDN：Date.prototype.getTime()——解释 Date 时间戳的毫秒单位。
- RFC 3339：Internet Date/Time Format——定义带 UTC 关系的互联网日期时间格式及示例。