时间戳转换在线

在线时间戳转换工具：填一串数字就自动认出它是 10 位秒、13 位毫秒、16 位微秒还是 19 位纳秒，换成北京时间、UTC、本机时区、ISO 8601 与 RFC 2822 写法，各带一键复制；反过来也能把日期时间换成 Unix 时间戳，还能一次转一整批、按 IANA 时区换算、UTC 与北京时间互换。首屏是实时跳的当前时间戳，秒与毫秒各一个大读数。全部在本机浏览器里算，不发网络请求。

怎么用

页面顶部常驻一句说明：这一页的换算全部在你这台设备的浏览器里完成，不发任何网络请求，填进来的内容不上传、不落盘。

首屏：当前时间戳

进页面就能看到两个实时跳的大读数：秒（现在是 10 位）与毫秒（现在是 13 位），各带一个复制按钮。秒读数是对齐整秒边界刷新的——每次都算到下一个整秒还差多少毫秒再跳，不是每隔 1000 毫秒盲跳一次，所以它和系统时钟的秒位是同步翻的。

要用鼠标选中数字复制，先点暂停，读数会停住，再点一次恢复走秒。下面一行同时给出当前的北京时间、UTC 与本机时区时间，本机那一格后面括号里写着你这台设备的时区偏移（正常在国内应该是 UTC+8，不是的话多半是系统时区设错了）。

页面切到后台标签页时走秒会停下来，回来自动接上——读的是系统时钟，不靠累加，切走再回来不会走偏。

一、时间戳 → 时间

把一串数字填进输入框，结果即时出来，不用点按钮（点转换或按回车也行）。

• 位数自动识别：11 位及以下当秒、12 到 14 位当毫秒、15 到 17 位当微秒、18 位及以上当纳秒。负数表示 1970 年以前。输入允许带正负号、空格、下划线和千位逗号，会自动忽略。
• 手动指定单位：自动认错了（比如你手上的是一串只有 4 位的秒数），在「单位」里直接选秒、毫秒、微秒、纳秒。
• 显示时区：默认北京时间，下拉里有二十来个常用 IANA 时区，夏令时交给浏览器自带的 Intl 实时算。

出来十行读数（所选时区本身就是北京时间或 UTC 时，重复的那一行不再列，是九行），第一行放大作主读数，每行右边都有复制：

16 位与 19 位的输入会保留毫秒以下的精度：结果的小数位上能看到完整的微秒或纳秒。这一步在支持 BigInt 的浏览器里走 BigInt，老浏览器退回按字符串截位，两条路算出来的结果逐字符一致（单元测试专门核过这一点）。

二、时间 → 时间戳

选日期、时刻（可精确到秒）、毫秒，再选这个时刻属于哪个时区，就得到对应的 Unix 时间戳（秒、毫秒、微秒、纳秒四种写法各一行）。四个快捷按钮：现在、今天 0 点、明天 0 点、本月 1 日——查日志区间的时候最常用。

下面那个框可以直接粘一段文本，认得这几种写法：

• 2026-09-17 21:05:09（也认 2026/9/17 21:05、2026.9.17）
• 2026-09-17T13:05:09.123Z（ISO 8601，末尾 Z 表示 UTC）
• 2026-09-17T13:05:09+08:00 或 -0500（自带偏移，这时上面选的时区不起作用）
• 只有日期的 2026-09-17（当成那天 0 点）

粘了文本就以文本为准；把它清空，才回到上面的日期时刻控件。

三、批量转换

一行一个，最多 2000 行，时间戳与日期时间可以混着放。结果是一张六列的表：原文、认成什么、所选时区、UTC、Unix 秒、Unix 毫秒。认不出的行单独标红并写清原因，不影响其余行。点复制结果得到制表符分隔的文本，贴进表格软件就是六列。

四、UTC ⇄ 北京时间

填一个时刻，两个按钮分别把它当成 UTC 换成北京时间、或当成北京时间换成 UTC，同时给出对应的时间戳。北京时间恒等于 UTC＋8，全年不变。

五、各语言里怎么取当前时间戳

页面底部有个折叠区，列了七种常用环境的标准写法，各带复制：JavaScript 的 Date.now() 与 Math.floor(Date.now() / 1000)、Python 的 time.time()、Java 的 System.currentTimeMillis()、Go 的 time.Now().Unix()、PHP 的 time()、MySQL 的 UNIX_TIMESTAMP()、Shell 的 date +%s。

怎么看结果

先看位数，再看年份

拿到一串来路不明的数字，判断顺序是：先数位数定单位，再看换出来的年份对不对。现在这个年代（2020 到 2030 年代）的时间戳，秒是 10 位、毫秒是 13 位、微秒 16 位、纳秒 19 位，这个对照关系一直到 2286 年才会变（那一年秒级时间戳会涨到 11 位）。

换出来的年份如果落在下面这几个位置，基本可以断定是单位错了：

毫秒以下的那几位

16 位和 19 位的时间戳，毫秒以下还有 3 位或 6 位。这些位在网页里只能显示，不能生成——浏览器能拿到的最细时刻就是毫秒，所以「时间 → 时间戳」那一页给出的微秒、纳秒写法末尾是补零的，页面上也写了这句话。真要纳秒精度，得在服务端用支持纳秒的接口取（Go 的 time.Now().UnixNano()、Java 的 Instant.now() 一类）。

页面提示的那几句

• 「按位数认成毫秒级」：自动识别的结果，不对就去「单位」里手动选。
• 「这一串里有不是数字的字符」：时间戳只能是整数；带小数点的（比如 Python 的 time.time() 直接打印出来的 1789999999.123456）先把小数点后的部分去掉，或者改填 13 位毫秒。
• 「换季那天把钟拨快了一小时，你填的这个当地时刻并不存在」：你选的时区正在实行夏令时，而你填的那个当地时刻落在被跳过的一小时里（比如美东三月调钟那天的 2:30）。结果按拨快之后的时刻算。
• 「这个当地时刻一天里出现了两次」：秋天拨回那天，同一个当地时刻会走两遍，结果按第一次（夏令时那一次）算。
• 「这个浏览器算不了 IANA 时区」：很老的浏览器没有完整的 Intl 时区数据，页面会退回固定偏移估算，此时不含夏令时，欧美时区的结果可能差一小时。北京与 UTC 不受影响（它们全年不调钟）。

跨时区核对的小技巧

同一时刻在不同时区只是显示不同。要核对一条日志到底出在什么时候，最稳的做法是：把时间戳填进来，同时看「UTC」和「北京时间」两行——UTC 那行拿去和服务器日志比，北京时间那行拿去和你自己的记忆比。想看更多城市、或者要排一个多方都方便的会议时间，去 世界时钟。

常见问题

时间戳能倒推出是哪台机器、哪个人生成的吗？

不能。时间戳只是一个数，它只表示「什么时候」，不含任何来源信息。会带来源信息的是另一类东西：v1 版的 UUID 会把生成那台机器的网卡地址写进去，v7 版会把生成时刻的毫秒写进去——如果你手上的是一串 UUID 而不是纯数字，可以拿去 UUID 生成器 的「校验与解析」页签，它能解出里面的版本与时间戳。

为什么我的时间戳换出来和同事的差 8 小时？

十有八九是某一环把「本地时间」当成了 UTC。典型场景：数据库里存的是不带时区的 DATETIME，写入时按北京时间写，读出来的程序却当 UTC 解析，于是整整差了 8 小时。排查办法是拿一条你确知发生时刻的记录，把它的时间戳填进本页，看「UTC」和「北京时间」哪一行对得上——对上 UTC 那行，说明写入端就是按 UTC 写的；对上北京时间那行，说明存的是本地时间，读的一端要改。另一种可能是设备本身时间不准，那属于另一件事，去 北京时间校准 量一下偏差。

负数时间戳合法吗？

合法，表示 1970 年之前。-1 秒就是 1969-12-31 23:59:59，-2208988800 秒是 1900 年 1 月 1 日。本页对负数做了严格的向下取整处理：-1 纳秒给出的是 1969-12-31 23:59:59.999999999，而不是把余数算反。要注意的是，不是所有语言和数据库都接受负时间戳，MySQL 的 FROM_UNIXTIME() 对负数就直接返回空，跨系统传递 1970 年以前的时间时最好改用日期字符串。

能把时间戳转成农历、或者算两个日期差几天吗？

本页不做农历。算日期间隔、往后推 N 天、某天是星期几、当年第几周这类事，去 日期计算器，那一页专门做这个，还带工作日计数。

和 time.is 一类的网站有什么不同？

那类网站的主业是「显示准确的当前时间、量你设备的时钟偏差」，时间戳只是顺带给一个读数。这一页反过来：主业是换算——位数自动识别、四种单位互转、批量、ISO 与 RFC 写法、按时区显示，是给开发和运维排查问题用的。要量自己设备准不准、想要满屏大字时钟，走 北京时间校准。

手机上好用吗？

好用。页面在 400 像素宽的屏幕上完整可见，表单会自动折行，长数字会换行显示，批量结果在手机上排成一行一张小卡，不用横着滚。手机上最常见的用法是：把某条通知里的一串数字长按复制，贴进来立刻知道那是什么时候。

原理与冷知识

• Unix 时间戳的起点是 1970-01-01 00:00:00 UTC。 这个日子被称作 Unix 纪元（epoch）。选它没什么宇宙意义——1970 年前后正是 Unix 成型的年份，取一个刚过去不久的整年，计数器的数值就不会太大。早期的实现甚至用过六十分之一秒作单位，那样一个 32 位整数只能装下两年多，很快就改成了秒。

• 2038 年问题是可以算出来的。 32 位有符号整数能表示的最大值是 2³¹ − 1 ＝ 2147483647。把这个数当成秒数从 1970 年数起，落点是 2038-01-19 03:14:07 UTC——再走一秒，整数溢出成负数，时间会翻回 1901-12-13。这就是所谓的「千年虫 2.0」。今天的 64 位系统早已用 64 位整数存时间，能撑到约 2920 亿年后；真正的风险留在没人再维护的嵌入式设备、老旧数据库字段和用 32 位整型存时间的历史表结构里。本页的单元测试专门核了这个日期，因为它不是背下来的，而是由 2³¹ − 1 直接算出来的事实。

• 一天恒为 86400 秒，是个约定不是事实。 地球自转并不均匀，真实的平太阳日会有毫秒级的偏差，靠闰秒把原子时和地球自转拉齐。Unix 时间戳选择完全忽略这件事：每天铁定 86400 秒。好处是时间戳与日期之间的换算成了纯算术，任何语言几行代码就能实现；代价是它严格说来不是「从纪元起真实流逝的秒数」。

• 时间戳里没有时区，也没有夏令时。 这是它最大的优点。夏令时的规则每个国家自己定、还时不时修改（最近这些年欧盟一直在讨论取消夏令时），历史上更是五花八门。系统里一旦把时间存成「本地时间字符串」，那些规则就全成了自己的负担；存时间戳，规则只在显示那一刻用一次，而且用的是操作系统或浏览器自带、会随系统更新的时区数据库。本页也是这么做的：时区与夏令时全部交给浏览器的 Intl，代码里没有写死任何一年的调钟日期。

• 为什么很多接口要的是毫秒。 秒的粒度在今天太粗了：一秒里可能有成千上万条日志，排序全靠先后顺序的场景（比如消息去重、乐观锁）秒级根本不够分。毫秒是个折中——13 位数字仍在 JavaScript 能精确表示的整数范围内（安全整数上限约 9007 万亿，而毫秒时间戳才 1.8 万亿），再往下到微秒 16 位虽然还没超，纳秒 19 位就超了，必须用 BigInt 或字符串处理，否则末几位会悄悄变成 0。本页处理 16 位与 19 位输入时优先走 BigInt，正是为了避开这个坑。

• ISO 8601 与 RFC 2822 各管一摊。 ISO 8601（2026-09-17T21:05:09+08:00）是给机器读的：字段定长、按字符串排序就等于按时间排序，几乎所有接口都收它。RFC 2822（Thu, 17 Sep 2026 21:05:09 +0800）来自电子邮件时代，HTTP 的 Date、Expires、Last-Modified 这些响应头至今还在用它，所以调 HTTP 缓存的时候常会碰上。两种写法本页都给，各带复制。

• 「时间搓」「时间错」不是错别字那么简单。 搜索里这两个词都有可观的量——大概率是拼音输入法把「戳」打成了别的字。这也侧面说明这个词的使用者主要是打字很快的开发者。真正规范的写法是时间戳，英文 timestamp，字面意思就是「盖在时间上的那个戳」。

• 时间戳为负的最著名事故。 早期不少系统用 0 表示「空值」，于是数据库里一堆记录的时间显示成 1970-01-01 08:00:00（北京时区下的 0 时间戳）。看到满屏的 1970 年，不必怀疑穿越，那通常意味着某个字段忘了赋值。同理，看到 2038-01-19 这个日期成片出现，那多半是某处把「最大值」当成了「永不过期」。