时间戳怎么转换成日期？Unix 时间戳与时区处理完整指南
Unix 时间戳是从 1970 年 1 月 1 日 00:00:00 UTC（Unix 纪元）开始经过的秒数，不包括闰秒。把时间戳转成日期，本质是把这个整数按目标时区还原成年月日时分秒；把日期转成时间戳，则是把某个时区的本地时间先换算成 UTC，再减去纪元起点。理解这一点，秒级与毫秒级的区分、2038 年溢出、时区偏移这几个常见坑就都能解释清楚。
时间戳的基础概念
Unix 时间戳记录的是一个绝对时刻，与任何时区无关。无论你身处北京还是纽约，同一个时间戳指向的是同一个物理时刻，差别只在于把它格式化显示时采用的时区不同。
两个参考值可以帮助你建立直觉：
- 2026 年 1 月 1 日 00:00:00 UTC 对应时间戳 1767225600
- 2038 年 1 月 19 日 03:14:07 UTC 对应时间戳 2147483647，这是 32 位有符号整数的上限
为什么用时间戳而不是日期字符串
跨时区一致性
时间戳基于 UTC，不受本地时区影响。存储和传输时用它，可以避免服务器时区与用户时区不一致导致的错位。
便于计算
比较两个时刻只需要做减法，得到的就是秒或毫秒差，不需要解析字符串，也不需要考虑月份天数、闰年等规则。
数据库索引效率
整数类型的时间戳比字符串类型的日期时间占用更小、比较更快，建索引和范围查询的效率更高。
API 数据传输
在 JSON 中传输时间戳比传输格式化日期字符串更紧凑，也免去了双方约定日期格式的麻烦。
常见时间戳格式对照
| 格式 | 示例 | 说明 |
|---|---|---|
| 秒级 | 1767225600 | 标准 Unix 时间戳，10 位 |
| 毫秒级 | 1767225600000 | JavaScript 常用，13 位 |
| 微秒级 | 1767225600000000 | 高精度场景，16 位 |
| ISO 8601 | 2026-01-01T00:00:00Z | 国际标准日期格式，末尾 Z 表示 UTC |
判断位数是最快的区分方法：10 位通常是秒，13 位通常是毫秒，16 位通常是微秒。位数对不上时，先怀疑单位而不是数值本身。
各语言中的转换方法
JavaScript
// 获取当前时间戳（毫秒）
Date.now()
// 时间戳转日期
new Date(1767225600000)
// 日期转时间戳
new Date('2026-01-01').getTime()
JavaScript 的 Date 以毫秒为准。如果你拿到的是秒级时间戳，需要先乘以 1000 再传给 Date，否则会得到 1970 年附近的错误日期。
Python
import time
# 获取当前时间戳
time.time()
# 时间戳转日期
import datetime
datetime.datetime.fromtimestamp(1767225600)
Python 的 time.time() 返回浮点秒数。fromtimestamp 默认按本地时区解释，需要 UTC 结果时应改用对应的 UTC 方法。
PHP
// 获取当前时间戳
time();
// 时间戳转日期
date('Y-m-d H:i:s', 1767225600);
// 日期转时间戳
strtotime('2026-01-01');
PHP 的 time() 返回秒级整数。date() 默认使用当前默认时区，strtotime() 解析不带时区的字符串时同样按默认时区处理。
手动转换的步骤
如果你需要在不依赖语言内置函数的情况下理解转换过程，可以按下面的步骤操作：
- 确认时间戳单位。数一数位数，10 位按秒处理，13 位先除以 1000 换算成秒。
- 把时间戳除以 86400，取整数部分得到从纪元起经过的整天数，余数就是当天经过的秒数。
- 用整天数推算日期。按公历规则累加年份和月份，注意闰年的二月有 29 天。
- 把余数拆成时、分、秒。余数除以 3600 得到小时，再除以 60 得到分钟，最后的余数是秒。
- 套用时区偏移。上一步得到的是 UTC 时间，要显示为某个时区的本地时间，需要加上该时区相对 UTC 的偏移量。
- 检查夏令时。部分时区在一年中会有一次偏移变化，转换跨越夏令时切换点的时刻时要特别确认。
时区处理要点
时间戳本身不带时区，时区只影响它被格式化成什么样子。处理时注意以下几点：
- 明确目标时区。同一个时间戳在东八区显示为上午 8 点，在 UTC 显示为当天 0 点。
- 偏移量不是固定的。有些时区存在夏令时，偏移量在一年中会变化，不能硬编码一个固定值。
- 存储用 UTC，展示用本地。数据库里存时间戳或 UTC 时间，输出给用户时再按用户时区转换，是更稳妥的做法。
- ISO 8601 中带 Z 表示 UTC，带具体偏移量如 +08:00 表示该时刻对应的本地时间，两者描述的是同一时刻的不同写法。
常见错误与注意事项
- 2038 年问题。32 位系统的时间戳会在 2038 年 1 月 19 日 03:14:07 UTC 溢出，应使用 64 位整数。
- 毫秒混淆。注意区分秒级和毫秒级时间戳，13 位通常是毫秒，直接当作秒处理会得到完全错误的日期。
- 时区处理。时间戳转日期时需明确目标时区，否则不同环境的默认时区会给出不同结果。
- 闰秒。Unix 时间戳的定义不包含闰秒，不要试图在转换中额外补偿闰秒。
- 字符串解析。把不带时区的日期字符串转成时间戳时，解析结果依赖运行环境的默认时区，跨环境时容易不一致。
在线时间戳转换工具
在线工具可以帮你快速完成转换，选择时留意它是否具备这些能力：
- 秒级和毫秒级时间戳的自动识别
- 实时转换，输入即出结果
- 同时显示多种格式的日期时间
- 支持自定义时区显示
常见问题
时间戳是秒还是毫秒，怎么快速判断？
先看位数：10 位按秒，13 位按毫秒，16 位按微秒。如果位数符合但转换结果明显偏离预期，再回头检查数值来源是否被截断或补零。
为什么同一时间戳在不同机器上转出的日期不一样？
因为格式化时使用的默认时区不同。时间戳本身是 UTC 的绝对时刻，差异出在显示环节。显式指定目标时区即可消除这种不一致。
2038 年之后时间戳还能用吗？
在 64 位整数环境下可以继续使用，64 位能表示的时间范围远超 2038 年。只有仍使用 32 位有符号整数存储时间戳的系统才会遇到溢出。
数据库里应该存时间戳还是日期时间类型？
两者都可以。时间戳的优点是不带时区歧义、计算方便；日期时间类型在部分数据库中有更直观的可读性和更丰富的函数支持。关键是在整个系统中保持统一，避免混用。
夏令时切换当天转换结果为什么会差一小时？
夏令时切换时，某个时区相对 UTC 的偏移量发生了变化。如果转换时使用了固定的偏移量，跨越切换点的时刻就会差一小时。应使用能感知夏令时的时区库来处理。