一、什么是 Unix 时间戳
Unix 时间戳（Unix timestamp / POSIX time）定义为从 1970 年 1 月 1 日 00:00:00 UTC 起经过的秒数，不包含闰秒。它是一个与时区无关的整数：同一时刻，全球任何地方拿到的时间戳都相同，只有「把它显示成人类可读日期」时才需要指定时区。
这一点是理解所有时区问题的关键：时间戳本身没有时区，转换结果才有。你在北京看到 2026-11-03 10:00，在伦敦同一时间戳显示为 02:00，两者都对。
二、10 位还是 13 位：秒与毫秒
- 10 位数字（如 1730610000）通常是秒级时间戳，后端、数据库、Linux 常见。
- 13 位数字（如 1730610000000）是毫秒级，JavaScript 的
Date.now()、Java 的System.currentTimeMillis()、很多前端埋点都用它。 - 还有 16 位微秒、19 位纳秒，多见于高精度日志与性能追踪。
换算关系很简单：毫秒 ÷ 1000 = 秒。一个实用判断法：当前年份（2026 年）附近的秒级时间戳约 1.7×10⁹（10 位），毫秒级约 1.7×10¹²（13 位）。把毫秒值当秒传入转换函数，会得到公元 5 万多年之后的日期，这是最常见的「转出来日期离谱」的原因。
三、各环境里的转换写法
# Linux / macOS
date -d @1730610000 # 按本地时区
date -u -d @1730610000 "+%F %T" # 按 UTC
date +%s # 当前秒级时间戳
# JavaScript
new Date(1730610000 * 1000).toLocaleString('zh-CN')
Date.now() // 毫秒
# Python
import datetime
datetime.datetime.fromtimestamp(1730610000) # 本地
datetime.datetime.fromtimestamp(1730610000, datetime.timezone.utc) # UTC注意 JavaScript 的 Date 构造函数接收的是毫秒，所以秒级时间戳必须乘 1000；而 Python 的 fromtimestamp 接收秒。两边混用是最经典的踩坑点。
四、为什么常常差 8 小时
中国标准时间是 UTC+8。如果接口返回 2026-11-03T02:00:00Z（末尾 Z 表示 UTC），直接把字符串里的「02:00」当成北京时间，就会少 8 小时。正确做法是先确认原始字符串是否带时区标识（Z 或 +08:00），再决定要不要加减偏移。用 时间戳转换工具 时，也留意输出面板选择的是「本地时间」还是「UTC」。
另一个坑是数据库里的 DATETIME 与 TIMESTAMP：前者不带时区、存什么显示什么，后者会按会话时区自动转换。跨机房部署时若会话时区不统一，同一个字段读出来会不一样。
五、2038 问题与边界
传统 32 位有符号整数能表示的最大秒数是 2147483647，对应 2038-01-19 03:14:07 UTC，再往后就会溢出成负数（回到 1901 年），这就是著名的 Y2038 问题。现代 64 位系统和数据库基本已规避，但老设备、嵌入式、部分 C 代码里的 time_t 仍需留意。另外 1970 年之前的时间戳是负数，很多前端组件默认不支持，做历史日期（如生日、档案）时要单独测试。
六、配套工具
批量换算、多时区对照可以用 时间戳转换；算两个日期之间差多少天用 日期计算；需要同时看北京、伦敦、纽约的时间，用 时区转换。所有计算都在浏览器本地完成，不用把日志时间戳贴到外部服务。
小结
先判断位数（10 位秒 / 13 位毫秒），再确认目标时区，最后核对原始字符串有没有 Z 或 +08:00。三步做完，时间戳转换基本不会再出错。