此刻
转换结果
| 格式 | 值 |
|---|
秒还是毫秒，靠位数判断而不是数值大小
这是最容易踩的坑：去掉负号后不超过 11 位的按「秒」处理（内部乘 1000），12 位及以上按「毫秒」处理。所以 1700000000 是秒、对应 2023 年，1700000000000 是毫秒、对应同一个时刻 —— 看错单位就差了 1000 倍。
也会碰到反例：1970 年代早期的毫秒时间戳本身只有 11 位，会被当成秒。这种情况只能自己判断，位数规则没法两全。
一次给出 8 种写法，各有用场
结果区同时列出：秒级时间戳、毫秒级时间戳、本地时间（带中文星期）、UTC 时间、ISO 8601、RFC 1123、toLocaleString 和时区偏移（形如 UTC+08:00）。每行右侧一个复制按钮。
给程序之间传递用秒或毫秒；写进日志文件用 ISO 8601；填 HTTP 头用 RFC 1123；跟人说话用本地时间。跨时区协作时给时间戳或 ISO 8601 最安全，别给「2026-01-01 08:00」这种没带时区的写法。
时区是本机时区，不是服务器时区
换算全部在你自己的浏览器里完成，用的是你电脑的系统时区。同一串时间戳，在北京的同事和在柏林的同事打开会看到不同的本地时间 —— 这不是算错了，是本地时间本来就依赖时区。
所以要确认一个时刻到底指哪一点，看 UTC 那一行：它不带时区偏移，是唯一不会因为机器设置而变的答案。页面另外单独列出时区偏移，方便你确认自己当前处在哪个偏移上。
不联网，也不记日志
所有换算走浏览器内置的 Date 对象，没有网络请求。把日志里的时间戳、数据库里的 created_at 粘进来查，不会有任何数据离开你的电脑。
输入也支持直接写时间文本，比如 2026-01-01 08:00:00 或 2026-01-01T08:00:00Z，浏览器能解析的写法基本都能吃；加了 Z 就按 UTC 解释，没加就按本地时区。
精度与边界
最小单位是毫秒，纳秒、微秒时间戳需要先截成毫秒（Unix 生态里 19 位是纳秒、16 位是微秒、13 位是毫秒、10 位是秒）。
不处理闰秒 —— JavaScript 的 Date 本身就没有闰秒概念，涉及高精度科学计时的场景请不要用这类工具核对。本页也不做两个时间之间的差值计算，算间隔请用日期计算工具。
常见问题
1700000000 到底是哪一天？
它是秒级时间戳（10 位），把工具切换到秒即可看到对应时间。位数规则是：去掉负号后 11 位以内按秒，12 位及以上按毫秒。
为什么我看到的和同事看到的差 8 小时？
本地时间那一行走的是你电脑的系统时区。要对齐请看 UTC 或 ISO 8601 那两行，它们与机器设置无关。
支持毫秒时间戳吗？
支持，13 位会按毫秒处理。结果区同时给出秒级和毫秒级两个值，可以直接对照。
能算两个时间相差多久吗？
不能。本页只做单个时刻的多种表示互换，计算间隔请用日期计算工具。
1970 年以前的时间能转吗？
能。负时间戳按负数处理，位数判定会先去掉负号，结果范围受 JavaScript Date 支持的范围限制（约 ±27 万年）。