Unix 时间戳换算器

纪元秒数 = 距 1970-01-01 的天数 × 86400 + 当天已过的 UTC 秒数；日期与时刻 = 同一套算术倒过来算

mode

选方向：填一个时间戳、返回日期，还是填日期与时刻、返回时间戳

timestamp

那个数本身，按单位字段是秒还是毫秒。只在「时间戳 → 日期」这个方向用得上

unit

你填的数是秒（本世纪的日期是 10 位）还是毫秒（13 位）。只在「时间戳 → 日期」这个方向用得上

date

UTC 的日历日，写成 YYYY-MM-DD。只在「日期 → 时间戳」这个方向用得上

time

UTC 的墙上时间，写成 HH:MM 或 HH:MM:SS。只在「日期 → 时间戳」这个方向用得上

utcDate

这个时间戳落在 UTC 的哪一天。这是本页的主结果

utcTime

UTC 的时刻，恒带秒。输入里不足一秒的部分是截断掉的，不是四舍五入

utcWeekday

那一天是星期几，用 0（周日）到 6（周六）的序号给出

isoDateTime

完整的 ISO 8601 写法，形如 2026-01-15T12:00:00Z，可以直接复制进代码或日志

timestampSeconds

同一个刹那折算成整秒的纪元值，截断而不是四舍五入，这样它不会和上面那行时刻互相矛盾

timestampMilliseconds

同一个刹那的毫秒值——秒数乘 1000，并保留输入里带的亚秒部分

要把一个数和一天对上号的时候用：读服务器日志、接口返回或数据库里的时间戳；判断别人给你的一个值到底是秒还是毫秒；或者生成一个时间戳存起来。本页只到 UTC 为止：它不换算成本地时间，也不问你所在时区——时间戳没有时区，诚实的答案就是一个 UTC 的答案，而把它读成本地钟面是时区计算器的事。它也不做时间戳的加减：要问「这个时刻再加三十天是哪天」，先换算、再去日期计算器。

1. 1768478400——那个参考时刻

   1. 单位填的是秒，所以这个数本身就是纪元值，不需要先做任何换算
   2. 除以 86400 得到距 1970 年 1 月 1 日的整天数，余数是当天已过的秒数：结果是 2026 年 1 月 15 日 12:00:00 UTC
   3. 2026 年 1 月 15 日是星期四，所以星期序号是 4
   4. 写成完整形式是 2026-01-15T12:00:00Z，也就是日志和接口里常见的那种写法
   5. 毫秒那一行是同一个刹那乘 1000，也就是系统按毫秒上报时同一个值的样子

   这是本页打开时的那一组值，值得当成锚点记住：1768478400 就是 2026 年 1 月 15 日的 UTC 正午。有一个熟悉的时间戳之后，其余换算都更容易一眼看出问题——算错通常错在整天的量级或者整个 1000 倍上，两种错误对着一个已知的锚点都会立刻现形。

2. 2147483647——32 位时代的最后一秒

   1. 2147483647 是 2 的 31 次方减一，也就是有符号 32 位整数能装下的最大数
   2. 把它当纪元秒数读，是 2038 年 1 月 19 日 03:14:07 UTC——这正是 2038 问题的由来：用那种类型存时间戳的系统再过一秒就装不下，会翻回 1901 年的某一天
   3. 2038 年 1 月 19 日是星期二，星期序号 2
   4. 秒数那一行原样返回这个数，这也就验证了它进去和出来走的是同一套算术

   这一条就是下面参考表里的那一行，送进计算器跑一遍。2038 问题不是「这个日期取不到」——本页算它毫无困难——而是用 32 位有符号数存时间戳的程序表示不了它的下一秒。64 位计数器在看得见的将来没有这个边界，所以同一个值写成毫秒就是 2147483647000。

3. 带亚秒的毫秒值：1768478400500

   1. 这个数有 13 位、单位填的是毫秒，所以它就是第一条那个刹那再加半秒
   2. 时刻那一行把小数丢掉而不是进位，所以读出来是 12:00:00 而不是 12:00:01
   3. 秒数那一行同样截断以保持一致：1768478400，不是 1768478401
   4. 毫秒那一行保留小数，因为结果是三行里唯一有这个精度的地方

   这是四舍五入与截断唯一会分出差别的一条，也是秒数那一行选择截断的理由。半秒进上去的话，秒数会比它正上方那行时刻大 1，读者对着两行比一眼就会认定其中一行坏了。让每一行都和显示出来的时刻自洽，比让每个整数取到最近的那个更重要。

4. 反方向：2026 年 1 月 15 日 12:00:30 UTC

   1. 日期先换成距 1970 年 1 月 1 日的天数，再乘 86400，得到到午夜为止的秒数
   2. 加上午夜之后的 30 秒：总数是 1768478430，也就是第一条那个值加 30
   3. 时刻字段收 HH:MM:SS，所以 12:00:30 是按秒读进来的，不会被抹成分钟
   4. 日期与星期两行原样返回，因为换出去再换回来是恒等变换

   对一个已经换算过的值再跑一遍反方向，是核对时间戳最省事的办法：如果来回一趟回不到原来那个数，多半是单位填错了。把一个 10 位的数按毫秒读，差的是整整一千倍，而它在这里的表现是给出 1970 年 1 月里的一天，而不是报错。

本页给出的每一个结果都是 UTC，不做本地时区换算——时间戳的定义里就没有时区，要把它读成本地钟面请用时区计算器。区间是 1970-01-01T00:00:00Z 到 2100-12-31T23:59:59Z，区间之外是报错而不是安静地算：负时间戳在 Unix 里合法、对应纪元之前的日期，但本页宁可明说自己只处理这一段，也不返回一个与正文自相矛盾的 1969 年答案。不足一秒的部分一律截断、不进位，所以毫秒值不会丢精度，但也不会影响显示出来的秒。本页不解析别的日期写法，不读你本机的时间戳，也不做加减——要问换算之后的日期再加三十天是哪天，请去日期计算器。另外，时间戳按 POSIX 的定义不含闰秒：闰秒确实会被加进 UTC，但一天恒按 86400 秒计，所以用两个时间戳相减去算「过了多少秒」时，中间夹着的闰秒是看不出来的。

UNIX 时间戳是什么？

UNIX 时间戳是从 1970-01-01T00:00:00 UTC 起算已经过去的秒数，这个零点就是所谓纪元。它也叫 epoch 时间或 POSIX 时间。它不含任何地点信息：定义本身就是按 UTC 计的，所以同一个刹那在全世界是同一个数，两台处在不同时区的机器哪怕本地钟面不一样，报出来的时间戳仍然相同。

时间戳怎么转日期？那个数是秒还是毫秒？

填进去、选好单位，日期和时刻就出来了；要做时间戳转日期，先看的其实是位数——本世纪的日期按秒算有 10 位，按毫秒算有 13 位。13 位的数按秒读会落到几万年之后，本页会拒绝；10 位的数按毫秒读会落到 1970 年 1 月，而这个错法不会报错，所以更值得当心。拿不准的时候用反方向换算回去，回不到原来的数就是单位填错了。

2038 问题是什么？

2038 问题指的是：用有符号 32 位整数存时间戳的系统，能表示的最大值是 2147483647，也就是 2038-01-19T03:14:07 UTC，再下一秒计数器就溢出、翻到 1901 年的某一天。这是那种存储类型的限制，不是时间戳本身的限制，64 位计数器没有这个问题。本页把那个值和它之后的值都算得出来，因为它用的是双精度浮点而不是 32 位整数。

应该存秒还是毫秒？

两种都在广泛使用，都不能算错，但一个数本身看不出是哪一种，所以单位必须跟着数一起走，或者事先约定好。毫秒能保留不足一秒的部分，JavaScript 的 Date 对象和不少日志系统用的是毫秒；秒是 POSIX 定义的单位，多数接口和数据库返回的是秒。两者之间就是乘或除 1000 的关系，本页把两行并排印出来，一眼就能看清这一对。

ISO 8601 和时间戳是同一个东西吗？

不是，而且两者容易混淆，因为它们描述的是同一个刹那。ISO 8601 是写法——2026-01-15T12:00:00Z，可读、可排序，末尾那个 Z 明确表示零时区；时间戳是一个不带任何格式的数。要粘进文档或 URL 里的是那个串，要存起来或拿来比较的是那个数。本页从同一次换算里把两者一起给出来，正好可以互相对照。

• 科普中国：UNIX 时间 — 科普中国（纪元、不含闰秒与 2038 问题的出处）
• 科普中国：多出的 1 秒，从何而来 — 科普中国（闰秒的由来）
• RFC 3339 — Date and Time on the Internet: Timestamps — IETF（本页打印的那个带 Z 的串的格式定义）