在数据库设计、API 接口返回以及分布式日志记录中，我们常常会见到诸如 1711200000 或 1711200000123 这样一长串纯数字。这就是计算机世界通用的Unix 时间戳（Unix Timestamp / Epoch Time）。
本文将为你梳理时间戳的核心机制、如何一眼辨别秒与毫秒、规避跨时区转换的隐蔽 Bug，并提供常用编程语言处理示例。
1. 什么是 Unix 时间戳？
Unix 时间戳定义为：从格林威治时间（UTC）1970 年 01 月 01 日 00 时 00 分 00 秒起，至当前指定时间所经过的总秒数（或毫秒数），不包含闰秒。
它的最大优势在于与时区无关：全球各地的服务器无论部署在东京、伦敦还是硅谷，在同一物理时刻所记录的 Unix 时间戳数值都是完全一致的，极大简化了分布式系统的时间同步与排序逻辑。
2. 10 位时间戳 vs 13 位时间戳的区别
日常调试接口时，很多开发者经常纳闷：为什么有的时间戳转出来是正常的 2026 年，有的转出来却变成了 1970 年或者几万年后？原因就在于单位混淆：
| 类型 | 数字位数 | 时间单位 | 典型技术栈 | 转换方法 |
|---|---|---|---|---|
| 秒级时间戳 | 10 位（如 1711200000） | 秒（s） | PHP (time())、MySQL (UNIX_TIMESTAMP())、Python (time.time()) |
乘以 1000 可转为毫秒 |
| 毫秒级时间戳 | 13 位（如 1711200000000） | 毫秒（ms） | JavaScript (Date.now())、Java (System.currentTimeMillis()) |
除以 1000 可转为秒 |
排查小技巧：如果发现将时间戳转换成时间后年份停留在 1970 年，99% 的原因是因为你把 10 位（秒）传给了期望 13 位（毫秒）的处理函数；反之如果年份变成了 50000 多年，则是因为把 13 位直接当成了 10 位秒处理。
3. 跨时区计算陷阱：UTC 与北京时间 (GMT+8)
将时间戳转换为格式化日期字符串（如 2026-03-23 15:30:00）时，必须明确指定当前时区：
- 同一时间戳，在格林威治（UTC+0）显示为
07:30:00，在我国北京时间（UTC+8 / 东八区）则显示为15:30:00，两者相差整整 8 个小时； - 若线上服务器未配置正确的时区（默认跑在 UTC 上），写入数据库的格式化时间就会出现“慢了 8 小时”的经典故障。
4. 主流编程语言时间戳获取与转换代码速查
JavaScript:
// 获取当前 13 位毫秒时间戳
const ms = Date.now();
// 10 位时间戳转格式化北京时间
const dateStr = new Date(1711200000 * 1000).toLocaleString('zh-CN', { timeZone: 'Asia/Shanghai' });PHP:
// 获取当前 10 位秒级时间戳
$timestamp = time();
// 格式化为北京时间字符串
date_default_timezone_set('Asia/Shanghai');
$formatDate = date('Y-m-d H:i:s', 1711200000);Python:
import time
from datetime import datetime
# 获取当前时间戳
current_ts = int(time.time())
# 时间戳转可读时间字符串
dt_object = datetime.fromtimestamp(1711200000)
print(dt_object.strftime("%Y-%m-%d %H:%M:%S"))5. 在线即时双向转换工具
在排查日志或分析数据表时，频繁手写转换函数非常耗时。推荐打开易处理 Unix时间戳转换工具：不仅能实时展示当前不断跳动的秒级与毫秒级时间戳，还支持任意字符串与时间戳的一键双向互转与时区选择。