做开发的几乎每天都要跟时间戳打交道。后端日志里打印了一串 1747891200，你瞪着眼睛看了半天，脑子里换算成 2026 年 X 月…尴尬了。
10 位还是 13 位？
这是新手最容易搞混的问题：
| 位数 | 单位 | 示例 | 说明 |
|---|---|---|---|
| 10 位 | 秒 | 1747891200 | 标准 Unix 时间戳 |
| 13 位 | 毫秒 | 1747891200000 | JavaScript 常用（含毫秒） |
怎么快速区分：看最后三位是不是 000。如果是十位，就说明这是秒级精度，后端接口常见。如果是十三位，就是毫秒级精度，JavaScript 的 Date.now() 输出的就是这种。
实际场景：前后端时间戳对接
我踩过的一个坑：
前端 JS 写 new Date().getTime() → 输出 13 位毫秒时间戳
后端 PHP 的 time() → 输出 10 位秒级时间戳
结果前端传的时间戳，后端解析出来是 1970 年…因为差了 1000 倍。
解决方案：用我们的 Unix 时间戳转换器 两边验证一下。把后端的时间戳粘进去，看看是不是你想要的日期；再把前端的时间戳粘进去，对比一下是不是同一个时间点。
实用技巧：处理时区问题
很多人疑惑：Unix 时间戳有没有时区？
答案：没有。 Unix 时间戳是世界统一的——它表示的是从 1970-01-01 UTC 开始经过的秒数。无论你在北京、纽约还是伦敦，同一个时间戳代表的绝对时刻是一样的。
差别在于显示：
- 北京：
2026-05-22 10:00:00 CST - 伦敦：
2026-05-22 02:00:00 UTC
用 时区转换器 可以同时查看多个时区的时间。
数据库里怎么存储？
| 数据库 | 建议类型 | 推荐理由 |
|---|---|---|
| MySQL | INT(11) 或 BIGINT | 操作简单，免去时区转换烦恼 |
| PostgreSQL | TIMESTAMPTZ | 原生支持时区 |
| SQLite | INTEGER | 存秒数，排序快 |
个人建议存时间戳（秒数），而不是 datetime 字符串。原因：
- 排序快 —— 整数比较比字符串快得多
- 时区无关 —— 存的时候什么时区，取出来还是什么时区
- 轻量 —— 4 字节 vs datetime 的 8 字节
在线工具省心
最省事的办法就是不要自己算。收藏我们的 Unix 时间戳转换器：
- 左边选日期 → 右边出时间戳
- 粘入时间戳 → 自动识别 10 位/13 位 → 显示人类可读时间
- 一键复制两种格式
再配合 在线年龄计算器 做日期间隔计算，简直前后端调试利器。
踩坑提醒
2038 年问题：32 位 INT 的最大值是 2147483647，对应 2038-01-19。如果用 32 位整数存时间戳，到了那天会溢出。所以新项目一律用 BIGINT（64 位），离地球毁灭都够用了。
接口文档要写清单位：每次对接时明确标注是秒（s）还是毫秒（ms），少踩一半的坑。