看到接口返回 1798924800，你知道它是什么时间吗？——它就是 Unix 时间戳：从 1970年1月1日 00:00:00 UTC 到这一刻经过的秒数。程序里到处用它，因为它不带时区、全球唯一、排序比较就是一个减法。本文讲清 10 位和 13 位的区别、怎么转换、以及最容易踩的时区坑。
为什么程序要用时间戳，而不是"2026-10-01 12:00"这种字符串？
- 时区无关："12:00"在北京和东京不是同一时刻，时间戳是全球唯一的绝对时刻；
- 比较与排序：判断两个事件谁先谁后，直接比大小，不需要解析字符串；
- 计算方便："7 天后"就是加 7×86400 秒；
- 存储紧凑：一个整数，比字符串省空间，索引也快。
10 位还是 13 位？先看长度
| 位数 | 单位 | 示例 | 常见来源 |
|---|---|---|---|
| 10 位 | 秒 | 1798924800 | Python time.time()、MySQL UNIX_TIMESTAMP() |
| 13 位 | 毫秒 | 1798924800000 | JavaScript Date.now()、Java System.currentTimeMillis() |
拿不准时看位数：10 位基本是秒、13 位基本是毫秒。把毫秒当秒去转，日期会跑到 1970 年附近；反过来则会转到几万年后。本站的时间戳转换工具按位数自动识别，不用手动切换单位。
最容易踩的坑：时间戳没有时区，显示才有
时间戳永远指向同一个绝对时刻，但显示成什么取决于时区。同一个时间戳，UTC 下是 04:00，北京时间就是 12:00。所以核对时间时先确认你看的是"本地时间"还是"UTC 时间"——很多"差了 8 小时"的事故，都是把 UTC 输出当成了北京时间。
各语言获取当前时间戳
JavaScript Date.now() // 毫秒
Python int(time.time()) // 秒
Java System.currentTimeMillis() // 毫秒
MySQL UNIX_TIMESTAMP() // 秒
Go time.Now().Unix() // 秒
2038 年问题，需要担心吗？
老系统的 32 位有符号整数最多存到 2038年1月19日（约 21.4 亿秒），之后溢出变负数。现代 64 位系统表示范围远超人类历史，日常开发无需处理；只有维护嵌入式老设备时才要留意。另一个实际限制：任何 64 位毫秒时间戳也只是到约 2.9 亿年后，够用。
时间戳转换
输入时间戳或选日期双向转换，秒/毫秒自动识别，本地时间与 UTC 对照显示
在线转换时间戳
做开发还常用到另外两个"看起来像加密其实是编码"的东西：Base64 编码和 MD5/SHA 哈希，它们的原理和误区分别在两篇文章里展开。