Unix 时间戳在线转换工具
免费的 Unix 时间戳在线转换工具，支持秒级（10 位）与毫秒级（13 位）双向转换，覆盖 UTC、北京、东京、纽约、伦敦等常用时区，输出 ISO 8601 标准格式与相对时间描述。完全浏览器本地计算。
最后更新：
当前时间
Unix 时间戳（秒）
Unix 时间戳（毫秒）
Asia/Shanghai
2026-06-29 15:01:54
时间戳 → 日期
日期 → 时间戳
输入时间按浏览器本地时区解释
各语言获取当前时间戳
| 语言 / 环境 | 秒级 | 毫秒级 |
|---|---|---|
| JavaScript | Math.floor(Date.now()/1000) | Date.now() |
| Python | int(time.time()) | int(time.time() * 1000) |
| Java | System.currentTimeMillis() / 1000 | System.currentTimeMillis() |
| Go | time.Now().Unix() | time.Now().UnixMilli() |
| PHP | time() | (int)(microtime(true) * 1000) |
| Rust | SystemTime::now().duration_since(UNIX_EPOCH)?.as_secs() | .as_millis() |
| Shell / Linux | date +%s | date +%s%3N |
| MySQL | UNIX_TIMESTAMP() | UNIX_TIMESTAMP(NOW(3)) * 1000 |
时间处理易错点
- 时区混乱：服务端、数据库、应用、客户端时区不一致是 90% 时间 bug 的根源。 推荐：存储用 UTC（或带 +08:00 的 ISO 8601），展示时再按用户时区转换。
- 2038 年问题：32 位 signed int 在 2038-01-19 后溢出。 现代语言/数据库（MySQL 8 的 TIMESTAMP 仍是 32 位）注意检查。
- 毫秒/秒混用：常见 bug：把毫秒戳当秒戳传给 PHP date()， 得到 5 万年后的日期。一律按位数判断或文档明确。
- 夏令时：跨 DST 的定时任务可能跳过或重复执行某小时， Kubernetes CronJob、cron 都受影响。
- 闰秒：Unix 时间戳忽略闰秒，所以日历秒和原子秒会逐渐失同步， 常规业务无影响，金融/科学场景需 TAI 时间。
- JavaScript Date 月份从 0 开始：
new Date(2024, 0, 1)才是 1 月，new Date(2024, 12, 1)是次年 1 月。
常见问题
Unix 时间戳是什么？为什么从 1970-01-01 算起？
Unix 时间戳是从 UTC 时间 1970-01-01 00:00:00（Unix Epoch）至今所经过的秒数（不计闰秒）。这个起点是 Unix 系统设计时定下的「零点」。32 位整数能存的最大值是 2147483647，对应 2038-01-19 03:14:07 UTC——即著名的「2038 年问题」，现代系统已普遍改用 64 位整数避免溢出。
怎么区分秒级（10 位）和毫秒级（13 位）时间戳？
看长度即可：10 位是秒（如 1700000000 = 2023-11-14），13 位是毫秒（如 1700000000000）。本工具会自动判断长度选择对应单位。注意 JavaScript 的 Date.now() 和 Java System.currentTimeMillis() 都返回毫秒；而 PHP time()、Python time.time() 默认返回秒。
为什么我转换出来的时间和数据库里的差 8 小时？
几乎都是时区问题。时间戳本身是绝对的（基于 UTC），但显示时按哪个时区格式化就显示哪个时区的时间。北京时间是 UTC+8。常见坑：1) MySQL 的 DATETIME 不带时区信息，存入时按服务器时区解释；2) 应用层、数据库层、操作系统时区不一致；3) 程序员用 new Date(string) 解析不带 Z 的时间字符串。统一用 UTC 存储 + 展示层转换是最佳实践。
JS 里 new Date('2024-01-01') 和 new Date('2024-01-01T00:00:00') 不一样？
对，这是 ECMAScript 规范的坑：纯日期格式（YYYY-MM-DD）按 UTC 解析，带时间的格式按本地时区解析。所以 new Date('2024-01-01') 在北京显示为 2024-01-01 08:00:00，new Date('2024-01-01T00:00:00') 显示 2024-01-01 00:00:00。建议总是带时区后缀，如 2024-01-01T00:00:00+08:00。
ISO 8601 是什么格式？为什么要用它？
ISO 8601 是国际标准的日期时间格式：YYYY-MM-DDTHH:mm:ss.sssZ，其中 T 分隔日期和时间，Z 表示 UTC（或用 +08:00 表示时区偏移）。优点：1) 跨语言、跨数据库无歧义；2) 字符串排序等同于时间排序；3) JSON、XML、HTTP 都推荐用它。本工具的「ISO 8601」输出可直接复制到 API 请求或数据库。
夏令时（DST）会影响时间戳吗？
时间戳本身不受夏令时影响——它永远是 UTC 秒数。但「按某地时区显示」会受影响：比如 America/New_York 在 3 月某天凌晨 2 点会直接跳到 3 点（该小时不存在），秋季会重复 1-2 点这一小时。本工具用浏览器 Intl API 处理时区，已自动考虑 DST 规则。