时间戳是所有机器唯一达成共识的时间数据，也恰恰是最常被读错的那一个。日志行、数据库字段和接口负载都同意 1757000000 的含义——从 epoch 起算的秒数所指向的那个绝对瞬间——而这块领域里几乎所有 bug 都来自时间戳本身不包含的东西：它没有时区，因为它不需要；它没有月份名称、星期几、偏移量，也不知道你说的到底是秒还是毫秒；它连闰秒都不包含——Unix 时间不计入闰秒，所以各家发布的 Unix 时间和 UTC 对照表偶尔会差一秒。本页外链到长期运营的 EpochConverter，下面讲的是真正引发过线上事故的那几类不匹配。
秒、毫秒，以及那个 13 位的错误
先数位数。十位是秒，十三位是毫秒，十六位或十九位通常是微秒或纳秒。1757000000 作为秒是 2025 年 9 月，作为毫秒则是 1970 年 1 月，相差约五十六年，于是每个看板都出现过那个著名的 1970 日期。反过来的错误同样常见：文档写明要毫秒的字段收到秒，日期就渲染成遥远未来的某一年。麻烦的起点在于各语言默认值不同：JavaScript 的 Date.now 和 Java 的 System.currentTimeMillis 是毫秒，PHP 的 time 是秒，Go 取决于是调 Unix 还是 UnixNano，Unix 命令行工具通常用 @ 前缀明确要秒。把单位搞错不会换来任何报错，只会换来一个看起来很合理的日期。
时区，以及时间戳表达不了的那两个瞬间
Unix 时间戳是不带时区的绝对瞬间，所以任何显示它的东西都得选一个时区，而每一次显示选择都是一个可能出错的地方。真正无解的是两种和夏令时有关的情况。春季调表时，缝隙里的本地挂钟时间根本不存在——在欧洲某时区，切换那个周日的 02:30 并不存在，把一个时间戳格式化成那个钟点会得到一个从未发生过的时刻。秋季调表时，同一个挂钟时间会出现两次，只看时间戳无法判断你指的是哪一次。JavaScript 还有一个值得知道的坑：只有日期的字符串，比如 2026-03-01，会按 UTC 解析；而没有时区的日期加时间，比如 2026-03-01 10:00，会按本地时间解析。看起来一样的字符串，两个不同的瞬间，这类 bug 只会在同事的电脑上才复现。
什么时候一行命令才是更好的答案
当你在读别人写下的东西时，转换器才真正划算：日志、导出文件、别人的文档。写自己的脚本时，命令行更快也绝不含糊。GNU coreutils 用 date -u -d @1757000000 打印瞬间；macOS 和 BSD 上是 date -u -r 1757000000，两套系统标志用法相反，混用会得到让人困惑的报错。Python 里用 datetime.datetime.fromtimestamp(1757000000, tz=datetime.timezone.utc) 保持时区显式，JavaScript 里 new Date(1757000000 * 1000).toISOString() 得到的是能正确排序、也能来回还原的 UTC 字符串。有一条能省时间的原则：在转换任何东西之前，先明确单位与时区，并把它们连同数值一起写进日志行。绝大多数时间戳事故其实是时区或单位事故，值后面加个 _ms 后缀或者显式带上 Z，本来就能避免。
常见问题
显示的是我本地时区的时间吗？
页面会按你选择的时区显示那个瞬间，而 epoch 数值本身不附带时区——这正是它的意义。比较不同机器或读日志时选 UTC，要告诉别人某件事发生在什么时候时选具体城市。注意：一台会出差的笔记本，对同一个时间戳会根据它当时的所在地显示不同结果。
epoch 从哪里开始算？
Unix 时间从 1970 年 1 月 1 日 00:00:00 UTC 起算秒数，也就是 1970 年元旦的 UTC 午夜，在此之前的时间是负值。这个惯例起自采用它的 Unix 操作系统，并且有意忽略闰秒，所以它并不是对 SI 秒的精确计数。
为什么我的时间戳和服务端日志差了八小时？
这个差值几乎总是时区偏移：服务端多半按 UTC 存储和打日志，而工具在按你的本地时间渲染。验证办法是选中 UTC 再看一次，如果这时和日志行一致，说明时间戳本身没问题，只是显示不同；如果差值不是整小时，那就轮到夏令时来背锅了。
这个工具免费吗？需要安装什么吗？
本页链接的服务是免费的，本站也一样。它跑在浏览器里，从日志窗口里读一个时间戳时很方便。但如果你一天到晚都在转时间戳，一条 shell 别名会比网页快得多。