Unix 时间戳就是一个数字：从 1970 年 1 月 1 日 00:00 UTC 起经过的秒数，数字内部不含任何时区。粘一个时间戳进来，你会得到同一时刻的各种写法：秒、毫秒、微秒、纳秒、ISO 8601、HTTP `Date` 头使用的 RFC 2822 形式，以及你所选时区的墙上时间。粘一个日期进来，则会得到对应的数字。
Unix 时间戳转换器 - Danfio
https://danfio.com/tools/unix-timestamp-converter/ - 从本页打印
按秒（自 1970 年起）读取
1735689600 秒
2025年1月1日星期三 00:00:00 UTC。在 UTC，这个瞬间是 2025-01-01 00:00:00（UTC+00:00），日期为 2025-01-01。
Unix 秒 1735689600 Unix 毫秒 1735689600000 Unix 微秒 1735689600000000 Unix 纳秒 1735689600000000000 ISO 8601（UTC） 2025-01-01T00:00:00.000Z RFC 2822 / HTTP Date Wed, 01 Jan 2025 00:00:00 GMT UTC 的日期与时间 2025-01-01 00:00:00 (UTC+00:00) UTC 的日期 2025-01-01 星期 星期三 ISO 周 2025-W01 JavaScript new Date(1735689600000)
每一行都是同一时刻的不同写法 —— 复制合适的那一行，或者用复制按钮取走全部。
最容易让人栽跟头的是单位：十位是秒，十三位是毫秒，两者相差的可能是 2026 年与 1970 年。这个页面会明确说出它按哪种单位解读，并给出同一串数字按另一种单位读会是什么——通常一眼就能看出错误出在哪里。
每一个格式化过的日期和时间背后都是一个整数，这个页面在两者之间来回移动：把时间戳变成秒、毫秒、微秒、纳秒、ISO 8601、RFC 2822 以及任意时区的墙上时间，也能把日期变回数字。
转换在浏览器本地完成，所以带标识符的生产日志行不会被发到任何地方。单位根据位数读取，并直白地写出来——十位是秒，十三位是毫秒——同时在旁边显示另一种读法，因为一千倍的误差会把时间送到 1970 年或公元 56000 年。
Unix 时间按秒计数，并且有意忽略闰秒，所以每天恰好是 86400 秒；这让算术保持简单，也让墙上时间偶尔与官方授时相差一秒。这个页面只负责转换并标明所用的解读，不替你判断哪个时区才是对的。
Unix 时间是自 1970-01-01T00:00:00Z 起经过的秒数。这个起点是系统设计时选定的，一直沿用至今。它也能向前数：64 位秒计数可以走到约 2920 亿年；向后同样有效，所以 1969 年及更早的时刻是负数，而不是错误。
它还忽略闰秒。UTC 会不时插入闰秒，让时钟跟上地球自转，而 Unix 时间有意不这么做：每一天都按恰好 86400 秒计算。这正是时间戳算术如此简单的原因，也是把时间戳换成墙上时间后，可能与官方授时相差一秒的原因。
时间戳是一个瞬间，不是一天中的某个钟点。数字里没有时区，所以 `1735689600` 本身既不是早晨也不是傍晚；只有确定了观察者所在的位置，它才会变成某个具体时刻。这个页面因此要求你选择时区而不是替你假定，也正因如此默认使用 UTC——那是所有人都能达成一致的读法。
不同工具选了不同的单位，而且通常不会说明自己用的是哪一种。多数 API 和所有服务端语言按秒计数；JavaScript 按毫秒计数，`Date.now()` 返回的就是十三位数字，所以来自浏览器的值通常是十三位；Postgres、链路追踪系统和高频日志使用微秒，还有一些数据管道使用纳秒。
一千倍的误差既容易忽略，又不可能忽略：毫秒值按秒读，会落到 1970 年 1 月；秒值按毫秒读，会飞到公元 56000 年，通常已经超出记录能保存的日期范围。这个页面根据位数判断单位，允许你手动覆盖，并清楚说明采用了哪种读法、另一种读法会得到什么。
当数值比毫秒更细时，日期部分会截断到毫秒，但数字列会完整保留原值，所以把一个纳秒值复制出去，仍然是进来时的那串数字。
时区数据来自浏览器自带的时间库，所以 `Asia/Tokyo` 和 `America/New_York` 无需额外下载，也不用维护一张会过期的偏移表。页面打印的偏移量是那个瞬间实际生效的偏移，而不是今天的偏移：纽约一月是 -05:00，七月是 -04:00；印度全年是 +05:30。
这也是为什么临近午夜时，“这是几点”可能不止一个正确答案：同一瞬间在一个时区是周一，在另一个时区已经是周二，页面上的星期行会跟随你选择的时区。面板顶部的日期同理，它是你所在时区的日期，而不是 UTC 日期。
日期只按 ISO 8601 解析，别的格式一概不接受。像 `12/25/2026` 这样的本地写法完全不会解析，因为对世界上相当一部分人来说它意味着 25 月 12 日，读取时只能靠猜。不带时区的日期字符串——例如 `2026-09-16T12:00`——会按 UTC 读取，结果里也会写明这一点。
示例使用页面自带的默认输入，只改设置；下面的结果与你在页面上看到的完全一致。
时间戳或日期: 1735689600 · 按什么单位读取数字: 根据位数自动判断 · 墙上时间显示时区: UTC
按秒（自 1970 年起）读取
1735689600 秒
2025年1月1日星期三 00:00:00 UTC。在 UTC，这个瞬间是 2025-01-01 00:00:00（UTC+00:00），日期为 2025-01-01。
毫秒: 1735689600000 · 星期: 星期三 · ISO 周: 2025-W01 · 时区: UTC
十位是秒，所以这个值会被读成 2025 年 1 月 1 日 00:00 UTC。下面的行会显示同一瞬间的毫秒值、ISO 日期，以及 HTTP Date 头形式。
时间戳或日期: 1735689600000 · 按什么单位读取数字: 根据位数自动判断 · 墙上时间显示时区: UTC
按毫秒（自 1970 年起）读取
1735689600 秒
2025年1月1日星期三 00:00:00 UTC。在 UTC，这个瞬间是 2025-01-01 00:00:00（UTC+00:00），日期为 2025-01-01。
毫秒: 1735689600000 · 星期: 星期三 · ISO 周: 2025-W01 · 时区: UTC
十三位是毫秒，也就是 JavaScript 产生的形式。结果下方的提示还会显示：如果把这串数字当成秒，会得到什么——因为这是这个工具最常遇到的错误。
时间戳或日期: 2026-09-16T12:00:00Z · 按什么单位读取数字: 根据位数自动判断 · 墙上时间显示时区: Asia/Tokyo
按ISO 8601 日期读取
1789560000 秒
2026年9月16日星期三 21:00:00 GMT+9。在 Asia/Tokyo，这个瞬间是 2026-09-16 21:00:00（UTC+09:00），日期为 2026-09-16。
毫秒: 1789560000000 · 星期: 星期三 · ISO 周: 2026-W38 · 时区: Asia/Tokyo
日期自带时区（`Z` 表示 UTC），墙上时间行则按东京显示：同一瞬间在东京是当天 21:00。
时间戳或日期: 2026-09-16 12:00 · 按什么单位读取数字: 根据位数自动判断 · 墙上时间显示时区: Europe/Berlin
按ISO 8601 日期读取
1789560000 秒
2026年9月16日星期三 14:00:00 CEST。在 Europe/Berlin，这个瞬间是 2026-09-16 14:00:00（UTC+02:00），日期为 2026-09-16。
毫秒: 1789560000000 · 星期: 星期三 · ISO 周: 2026-W38 · 时区: Europe/Berlin
不带时区的日期字符串在这里按 UTC 读取，结果会明确说明；柏林行则显示该日期实际适用的偏移。切换单位设置后，同一串数字也可以按秒解读，这正是单位覆盖选项的用途。
它是 1970 年 1 月 1 日 00:00:00 UTC 到所问时刻之间的秒数，不附带任何时区。更早的时刻可以是负数；它有意忽略闰秒，所以每一天都被当作 86400 秒。这就是时间戳能一步完成转换的原因，也是由它推导出的墙上时间可能与官方授时相差一秒的原因。
几乎总是因为单位与页面假定的不同。十位是秒，十三位是毫秒（JavaScript），十六位是微秒，十九位是纳秒。毫秒值按秒读会落到 1970 年 1 月；秒值按毫秒读会飞到公元 56000 年，通常已经超出记录能保存的日期范围。单位设置可以覆盖读取方式，结果里始终会说明用了哪种读法、另一种读法会得到什么。
原因在时区，而且通常是夏令时。纽约一月是 -05:00，七月是 -04:00；柏林是 +01:00 与 +02:00；印度全年是 +05:30。这里打印的偏移量是那个瞬间实际生效的偏移，而不是今天的偏移，所以七月的时间戳在 Europe/Berlin 时区下会显示夏季偏移。如果时间看起来差一小时，先检查时区字段和该行的偏移量，而不是怀疑算术。
大量软件把时间戳存成有符号 32 位整数，它的上限是 2,147,483,647 秒，也就是 2038 年 1 月 19 日 03:14:07 UTC。这个值仍在 JavaScript 日期的范围内，所以在这里转换毫无问题——问题出在那些再也装不下它的旧软件里。现代系统使用 64 位，可以走到约 2920 亿年；JavaScript 使用毫秒，安全到 275760 年。
两者各有用途。数字紧凑、排序正确、不携带时区歧义，算术也极其简单，所以数据库和 API 用它。日期字符串人能读、能自描述，所以用于交换和日志。真正该避免的错误，是一个不写明单位的裸数字：把列名带上单位，例如 `created_at_ms` 而不是 `created`，因为十位和十三位看起来很像，含义却差得极远。
因为它无法被无歧义地读取。`12/25/2026` 在美国是圣诞节，在所有先写日的地区却是 25 月 12 日，浏览器只能靠猜——而 `Date.parse` 正是这么做的，并且不同浏览器猜得不一样。这里的日期一律用 ISO 8601：2026-12-25，可选带时间和时区。多花一点时间输入，能消掉一整类缺陷。
单靠它并不安全。时间戳来自墙上时钟，而墙上时钟会被校正：NTP 可能把时钟往回拨零点几秒，从快照恢复的虚拟机可能往回拨得更多。要在单台机器内排序，应使用单调时钟或序列号；要跨机器排序，应使用时间戳加一个决胜字段，例如逻辑时钟，或一个内嵌时间与计数器的标识符。时间戳回答的是“这件事发生在什么时候”，不是“哪件事先发生”。
因为 Unix 时间没有第 60 秒：一天被定义为 86400 秒，闰秒被吸收而不是被计数。存储的数据几乎总是把 2016-12-31T23:59:60 写成下一分钟的第一秒，这也是这个页面会接受并转换的写法。如果你手里的值确实写着 `:60`，它来自某种广播时间尺度，而不是 Unix 时间戳。
最近复核于 2026-09-16.
本页在您的浏览器本地运行，请保留原文件备份；不涉及财务建议。 阅读完整免责声明。
Danfio 中文在线工具