核心答案：Unix 时间戳 = 从 1970-01-01 00:00:00 UTC 到现在的秒数（毫秒版 ×1000）。判断单位看位数：10 位=秒，13 位=毫秒。1735689600 = 2025-01-01 08:00:00 北京时间。
时间戳基础
- 起点（Epoch）：1970-01-01 00:00:00 UTC
- 秒级：10 位数字（到 2286 年才变 11 位）
- 毫秒级：13 位数字（JS 的 Date.now()）
- 微秒/纳秒：16/19 位（Go、数据库高精度场景）
| 时间戳 | 含义 |
|---|---|
| 0 | 1970-01-01 00:00:00 UTC |
| 1735689600 | 2025-01-01 00:00:00 UTC |
| 2147483647 | 2038-01-19（32 位上限） |
秒与毫秒
| 特征 | 秒级 | 毫秒级 |
|---|---|---|
| 位数 | 10 | 13 |
| 典型来源 | Unix/Linux/PHP | JavaScript/Java |
| 1735689600 | ✓ | 需 ÷1000 |
混用事故：把毫秒当秒传入 → 日期变成 56000 多年后；把秒当毫秒 → 1970 年 1 月。收到时间戳先数位数。
时间戳转日期
手动心算参考点：
- 每天 86400 秒
- 每年约 31557600 秒（365.25 天）
- 1735689600 是 2025 元旦（好记的锚点）
编程转换：JS new Date(1735689600000)、Python datetime.fromtimestamp(ts)。
时区怎么处理
铁律：时间戳本身没有时区——它是全球统一的绝对时刻。
| 环节 | 做法 |
|---|---|
| 存储 | 永远存 UTC 时间戳或 timestamptz |
| 传输 | ISO 8601 带偏移：2025-01-01T08:00:00+08:00 |
| 展示 | 前端按用户本地时区格式化 |
北京时间 2025-01-01 08:00:00 = UTC 00:00:00，对应同一时间戳 1735689600。
2038 年问题
32 位有符号整数最大 2147483647，对应 2038-01-19 03:14:07 UTC——之后秒级时间戳溢出回绕到 1901 年。
- 现代 64 位系统已无忧（能用到 2920 亿年后）
- 风险在：老嵌入式设备、32 位 MySQL 的 UNIX_TIMESTAMP、遗留金融系统
- 类似千年虫，需要提前升级
常见误区
- 给时间戳加时区偏移：时间戳是绝对时刻，"北京时间戳+28800"是双重计算错误。
- 前端直接 new Date(秒)：JS 要毫秒！秒级传入得到 1970 年的日期。
- 数据库用 timestamp 类型：MySQL timestamp 有 2038 上限且隐式时区转换，用 bigint 存时间戳更稳。
- 本地时间字符串直接存库："2025-01-01 08:00" 没带时区，换服务器时区全乱。
用[时间戳转换工具](/c/dev/timestamp)互转时间戳与日期时间，自动识别秒/毫秒。