Unix 时间戳完全指南：从 Epoch 到 2038 问题
时间戳的起点：为什么是 1970 年 1 月 1 日
Unix 时间戳的定义很简单：从协调世界时（UTC）1970 年 1 月 1 日 00:00:00 起经过的秒数。这个起点被称为 Unix Epoch。但为什么选 1970 年？
1970 年左右是 Unix 操作系统最初开发的时期。Ken Thompson 和 Dennis Ritchie 在 Bell Labs 开发 Unix 时，需要一个简单的计时方案。他们选择了 1970 年 1 月 1 日作为参考点——这个日期足够早（那时 Unix 还没发布），但又不至于让时间值太大。实际上，Unix 时间最初是以 1/60 秒为单位存储在一个 32 位整数中的（因为当时的系统时钟频率是 60Hz），后来才改为 1 秒为单位。
现在，Unix 时间戳已经成为计算机世界事实上的时间标准。几乎所有的编程语言、数据库、日志系统都使用 Unix 时间戳来记录时间——因为它是一个简单的数字，不涉及时区、格式、语言等复杂问题。
秒 vs 毫秒时间戳：开发中最容易混淆的地方
这是几乎所有开发者都踩过的坑：不同系统使用不同精度的时间戳。如果你看到一个时间戳，首先要判断它是秒级还是毫秒级：
秒级时间戳： 1746403200 (10位数字，对应 2026-05-05)
毫秒级时间戳：1746403200000 (13位数字，同一时刻)
微秒级时间戳：1746403200000000 (16位数字)常见的规则：
- JavaScript Date.now()： 毫秒
- Python time.time()： 秒（浮点数，含小数部分表示微秒）
- MySQL UNIX_TIMESTAMP()： 秒
- Java System.currentTimeMillis()： 毫秒
- Go time.Now().Unix()： 秒；.UnixMilli()：毫秒
- 大多数 API（如微信支付、阿里云）： 毫秒
2038 年问题：32 位时间戳的"世界末日"
32 位有符号整数可以表示的最大值是 2,147,483,647（约 21 亿）。从 1970 年 1 月 1 日开始数这么多秒，正好到达 2038 年 1 月 19 日 03:14:07 UTC。之后，时间戳会溢出变为负数（有符号整数溢出），导致系统时间跳回 1901 年。
这个问题和 2000 年的 Y2K 问题本质上是一样的。但 Y2038 的影响可能更大，因为时间戳嵌入在无数的嵌入式系统、旧数据库、文件格式和网络协议中。好消息是，大多数现代系统已经切换到 64 位时间戳（可以支撑到宇宙热寂），但遗留系统仍然需要关注。
如果你在维护使用 32 位 time_t 的 C/C++ 程序，或者在处理某些旧格式的文件（如 ZIP 文件使用 32 位时间戳），现在就应该开始迁移计划。
时区的陷阱：时间戳本身不带时区
Unix 时间戳记录的是从 UTC Epoch 起经过的秒数，它与时区无关。同一个时间戳在全世界任何地方代表的是同一个瞬间。问题出在"把时间戳转换为人可读的日期时"需要指定时区。
时间戳 1746403200：
在 UTC+0 显示为：2026-05-05 00:00:00
在 UTC+8（北京时间）显示为：2026-05-05 08:00:00常见的坑：
- 服务器在 UTC 时区，数据库存的是本地时间而非时间戳 → 转换时差了 8 小时
- 前端用
new Date(timestamp)会自动使用用户浏览器的时区显示，但后端可能是 UTC - 跨时区团队协作时，有人按北京时间记录，有人按 UTC 记录
最佳实践是：存储和传输一律使用 UTC/时间戳，只在展示层转换为用户本地时区。
时间戳转换工具的正确使用
在线时间戳转换工具的核心价值在于快速验证——面对日志里的一串数字，不需要写代码就能知道它对应哪个时刻。典型使用场景：
- 分析服务器日志： Nginx、Apache 等日志中的时间戳快速转为人可读格式
- 调试 API 参数： 确认请求参数中的时间戳是否正确
- 跨系统时间核对： 对比不同系统对同一时间戳的解析结果