时间戳转换：Unix 时间戳与北京时间互转（秒 / 毫秒 / 微秒）
Unix 时间戳是"从 1970-01-01T00:00:00Z 起经过的秒数"，它记录的是一个绝对瞬间，本身不带时区——同一个时间戳，UTC 读到的是一个时刻，北京（UTC+8）读到的是再往后 8 小时的钟面时间。今天是 2026年10月31日 星期六，下面这组数就是页面生成那一刻的真实值，打开后由脚本按你设备的时钟每秒刷新。
时间戳不会因为你换个时区就变化；会变的只有"读数"。今天（北京 2026年10月31日）已经走过 0 秒，UTC 的今天（2026-10-30）已走过 57,600 秒。全页口径：时间戳是"从 1970-01-01T00:00:00Z 起经过的秒数"，它记录的是一个绝对瞬间，本身不带时区；UTC、北京、东京的读数只是同一个瞬间在不同钟面上的投影。本页所有换算都按这个口径，秒级/毫秒/微秒互转只是乘除 1000，不做任何"本地时间"猜测。
时间戳转换计算器（双向换算）
① 时间戳 → 日期时间：填一串数字，自动识别秒 / 毫秒 / 微秒
毫秒 1,793,376,000,000
微秒 1,793,376,000,000,000
| 时区 | 当地日期时间 | 星期 | 与 UTC 的偏移 |
|---|---|---|---|
| UTC 协调世界时 UTC |
2026-10-30 16:00:00 | 星期五 | UTC+00:00 UTC+00:00 全年有效 |
| 北京 中国标准时间 CST |
2026-10-31 00:00:00 | 星期六 | UTC+08:00 UTC+08:00 全年有效 |
| 东京 日本标准时间 JST |
2026-10-31 01:00:00 | 星期六 | UTC+09:00 UTC+09:00 全年有效 |
| 纽约 美国东部时间 ET |
2026-10-30 12:00:00 | 星期五 | UTC-04:00 夏令时 夏令时 UTC-05:00 → UTC-04:00 |
| 伦敦 英国时间 UK |
2026-10-30 16:00:00 | 星期五 | UTC+00:00 UTC+00:00 全年有效 |
同一个时间戳在五个时区的读数：从 UTC 依次加 8 小时（北京）、9 小时（东京）、减 5 或 4 小时（纽约）、加 0 或 1 小时（伦敦，夏令时）。纽约与伦敦按现行夏令时规则逐瞬间判定：美国 3 月第二个周日 — 11 月第一个周日，英国/欧盟 3 月最后一个周日 — 10 月最后一个周日。
② 日期时间 → 时间戳：按北京时间（UTC+8）解释
以上按北京时间（UTC+8）解释：同一个钟面时间，UTC 读数是 2026-10-30 16:00:00，比它少 28800 秒。选 1900—2100 年之外的年份不在本页范围内。
口诀：时间戳 = 北京钟面时间按 UTC 算 − 28800；把时间戳读成北京时间则反过来 + 28800。上面的数字都是秒级，毫秒级 / 微秒级只是同一个数乘 1000 / 1000000。
常用时间戳锚点表（秒级 / 毫秒级对照）
这些数值都已逐个核对：秒级 0 就是 Unix 纪元，1000000000 是"十亿秒"，2147483647 是 32 位有符号整数的上限。第一列给北京时间，小字给同一瞬间的 UTC 读数——两列相差恰是 8 小时。
| 日期时间（北京） | 秒级 | 毫秒级 | 备注 |
|---|---|---|---|
| 1970-01-01 08:00:00 UTC 1970-01-01 00:00:00 |
0 | 0 | Unix 纪元 UTC 1970-01-01 00:00:00；北京时间当天 08:00:00，相差 28800 秒 |
| 1970-01-01 07:59:59 UTC 1969-12-31 23:59:59 |
-1 | -1,000 | 纪元前一秒 1970 年以前的时间戳是负数：-1 = 1969-12-31 23:59:59 UTC |
| 2000-01-01 08:00:00 UTC 2000-01-01 00:00:00 |
946,684,800 | 946,684,800,000 | Y2K（2000-01-01） UTC 2000-01-01 00:00:00；北京 2000-01-01 08:00:00 |
| 2000-01-01 00:00:00 UTC 1999-12-31 16:00:00 |
946,656,000 | 946,656,000,000 | 2000 年元旦（北京 0 点） 同一个"2000 年元旦"，按北京时间取 0 点会落在 UTC 的 1999-12-31 16:00:00，相差 28800 秒 |
| 2001-09-09 09:46:40 UTC 2001-09-09 01:46:40 |
1,000,000,000 | 1,000,000,000,000 | 十亿秒 UTC 2001-09-09 01:46:40；北京 2001-09-09 09:46:40。程序员的"十亿秒"纪念时刻 |
| 2038-01-19 11:14:07 UTC 2038-01-19 03:14:07 |
2,147,483,647 | 2,147,483,647,000 | 32 位上限 UTC 2038-01-19 03:14:07；北京 2038-01-19 11:14:07。32 位有符号整数能表示的最大秒数 |
| 2038-01-19 11:14:08 UTC 2038-01-19 03:14:08 |
2,147,483,648 | 2,147,483,648,000 | 32 位溢出第一秒 UTC 2038-01-19 03:14:08；北京 11:14:08。32 位 int 会回卷成 -2147483648 |
| 1970-01-01 00:00:00 UTC 1969-12-31 16:00:00 |
-28,800 | -28,800,000 | 1970 年元旦（北京 0 点） UTC 读数是 1969-12-31 16:00:00（比北京慢 8 小时） |
| 2010-01-01 00:00:00 UTC 2009-12-31 16:00:00 |
1,262,275,200 | 1,262,275,200,000 | 2010 年元旦（北京 0 点） UTC 读数是 2009-12-31 16:00:00（比北京慢 8 小时） |
| 2020-01-01 00:00:00 UTC 2019-12-31 16:00:00 |
1,577,808,000 | 1,577,808,000,000 | 2020 年元旦（北京 0 点） UTC 读数是 2019-12-31 16:00:00（比北京慢 8 小时） |
| 2025-01-01 00:00:00 UTC 2024-12-31 16:00:00 |
1,735,660,800 | 1,735,660,800,000 | 2025 年元旦（北京 0 点） UTC 读数是 2024-12-31 16:00:00（比北京慢 8 小时） |
| 2026-01-01 00:00:00 UTC 2025-12-31 16:00:00 |
1,767,196,800 | 1,767,196,800,000 | 2026 年元旦（北京 0 点） UTC 读数是 2025-12-31 16:00:00（比北京慢 8 小时） |
| 2027-01-01 00:00:00 UTC 2026-12-31 16:00:00 |
1,798,732,800 | 1,798,732,800,000 | 2027 年元旦（北京 0 点） UTC 读数是 2026-12-31 16:00:00（比北京慢 8 小时） |
| 2030-01-01 00:00:00 UTC 2029-12-31 16:00:00 |
1,893,427,200 | 1,893,427,200,000 | 2030 年元旦（北京 0 点） UTC 读数是 2029-12-31 16:00:00（比北京慢 8 小时） |
| 2038-01-01 00:00:00 UTC 2037-12-31 16:00:00 |
2,145,888,000 | 2,145,888,000,000 | 2038 年元旦（北京 0 点） UTC 读数是 2037-12-31 16:00:00（比北京慢 8 小时） |
"各年元旦（北京 0 点）"那几行说明的是：同一个 1 月 1 日，按北京时间取 0 点与按 UTC 取 0 点，时间戳相差 28800 秒。今天是 2026年10月31日，0 点整（北京）的时间戳是 1,793,376,000。
位数与范围边界：10 位 / 13 位 / 16 位
三种单位写满之后指向的是同一个瞬间：10000000000 秒 = 2286-11-20 17:46:40 UTC（北京 2286-11-21 01:46:40）。也就是说，只要时间戳还在这天之前，位数就够用；越界之后必须升位或换单位。
| 位数 | 单位 | 可表示范围（正数，UTC 读数） | 典型场景 | 溢出点 |
|---|---|---|---|---|
| 10 位 | 秒级 | 1970-01-01 00:00:00 — 2286-11-20 17:46:39 数值 9 999 999 999（UTC 读数） |
Unix/Linux、PHP、Python、SQL 的 UNIX_TIMESTAMP()，当下几乎所有系统的默认输出 | 2286-11-20 17:46:40 UTC 北京 2286-11-21 01:46:40 · 再走一秒就变成 11 位，10 位放不下 |
| 13 位 | 毫秒级 | 1970-01-01 00:00:00.000 — 2286-11-20 17:46:39.999 数值 9 999 999 999 999（UTC 读数） |
JavaScript Date.getTime()、Java System.currentTimeMillis()、MySQL 毫秒精度字段 | 2286-11-20 17:46:40 UTC 北京 2286-11-21 01:46:40 · 再走一毫秒就变成 14 位 |
| 16 位 | 微秒级 | 1970-01-01 00:00:00.000000 — 2286-11-20 17:46:39.999999 数值 9 999 999 999 999 999（UTC 读数） |
Go time.Now().UnixMicro()、Python 微秒字段、部分数据库与日志的高精度时间列 | 2286-11-20 17:46:40 UTC 北京 2286-11-21 01:46:40 · 再走一微秒就变成 17 位；17 位以上也已超出 JS 精确整数范围 |
带负号可以表示 1970 年以前，位数表只约束正数写法：例如 −1 = 1969-12-31 23:59:59 UTC。微秒级 16 位数字已接近 JavaScript 能精确表示的整数上限（约 9.007×10¹⁵），超过 16 位请改用字符串或 BigInt 处理。
单位换算表：1 秒 / 分 / 时 / 天 / 周 / 年
秒级与毫秒级互转就是乘除 1000，与微秒级互转乘除 1000000。下表给的是"1 个时间单位等于多少毫秒、多少微秒"。
| 时间长度 | 等于多少毫秒 | 等于多少微秒 | 说明 |
|---|---|---|---|
| 1 秒 | 1,000 毫秒 | 1,000,000 微秒 | 时间戳的最小常用单位：秒级时间戳每秒 +1 |
| 1 分钟 | 60,000 毫秒 | 60,000,000 微秒 | 60 秒 |
| 1 小时 | 3,600,000 毫秒 | 3,600,000,000 微秒 | 3600 秒 |
| 1 天 | 86,400,000 毫秒 | 86,400,000,000 微秒 | 86400 秒；时间戳每过一天正好加 86400 |
| 1 周 | 604,800,000 毫秒 | 604,800,000,000 微秒 | 7 天 = 604800 秒 |
| 1 个月（按 30 天） | 2,592,000,000 毫秒 | 2,592,000,000,000 微秒 | 自然月 28—31 天，只能按 30 天折算 |
| 1 年（平年 365 天） | 31,536,000,000 毫秒 | 31,536,000,000,000 微秒 | 365 × 86400 = 31,536,000 秒 |
| 1 年（闰年 366 天） | 31,622,400,000 毫秒 | 31,622,400,000,000 微秒 | 366 × 86400 = 31,622,400 秒 |
反过来：1 毫秒 = 0.001 秒，1 微秒 = 0.000001 秒 = 0.001 毫秒。时间戳做减法得到的是秒差，除以 86400 就是天差。
同一时间戳在不同时区的读数（每日更新）
以当前时刻的时间戳 1,793,376,000 为例，同一瞬间在五个时区的读数如下。时间戳不变，变的只是钟面时间；纽约与伦敦的偏移会随夏令时切换，北京、东京、UTC 全年不变。
| 时区 | 当地日期时间 | 星期 | 与 UTC 的偏移 |
|---|---|---|---|
| UTC 协调世界时 UTC |
2026-10-30 16:00:00 | 星期五 | UTC+00:00 UTC+00:00 全年有效 |
| 北京 中国标准时间 CST |
2026-10-31 00:00:00 | 星期六 | UTC+08:00 UTC+08:00 全年有效 |
| 东京 日本标准时间 JST |
2026-10-31 01:00:00 | 星期六 | UTC+09:00 UTC+09:00 全年有效 |
| 纽约 美国东部时间 ET |
2026-10-30 12:00:00 | 星期五 | UTC-04:00 夏令时 夏令时 UTC-05:00 → UTC-04:00 |
| 伦敦 英国时间 UK |
2026-10-30 16:00:00 | 星期五 | UTC+00:00 UTC+00:00 全年有效 |
数据随 2026年10月31日 自动更新；刷新页面后由脚本按你设备的时钟实时重算。历史时区变更（1970 年前各地夏令时、时区调整）不在本页范围内。
口径说明
时间戳为什么没有时区
时间戳是"从 1970-01-01T00:00:00Z 起过了多少秒"的计数，它记录的是一个绝对瞬间的坐标，跟观察者在哪儿无关。UTC、北京、东京的读数只是同一个瞬间在不同钟面上的投影：北京 = UTC+8，所以 北京时间 = 时间戳读数 + 8 小时。所谓"把时间戳转成北京时间"并不是换算，而是"按 UTC+8 这个偏移量去读同一个瞬间"。这也是为什么本页在任何地方都同时给出 UTC 与北京两个读数——只给一个，就容易被误当成"两个不同的时间"。
10 位和 13 位怎么区分
按位数：10 位是秒级（现在约 1.7×10⁹）、13 位是毫秒级（约 1.7×10¹²）、16 位是微秒级（约 1.7×10¹⁵），纳秒级则是 19 位。三者是同一个瞬间换单位，相差正好 1000 倍。自动识别只认位数：整数部分 ≤ 11 位当秒、12—14 位当毫秒、≥ 15 位当微秒；想强制按某种单位读，在第一组面板的"单位"里手动选即可，识别依据会写在结果里。位数表也不是永远有效——到 2286-11-20 17:46:40 UTC 之后 10 位秒就写不下了。
2038 年问题是什么
32 位有符号整数最大 2147483647，对应 2038-01-19 03:14:07 UTC（北京当天 11:14:07）。再过去一秒就溢出回卷成 −2147483648 = 1901-12-13 20:45:52 UTC，老程序里的日期会突然倒退回 1901 年。64 位系统不受影响（可用到约 2920 亿年后），但嵌入式设备、以 INT 存时间戳的老数据库字段、老协议仍在用 32 位，所以本页把 2147483647 和溢出后的 2147483648 都列进了锚点表。今天（2026年10月31日）距离这个上限还有约 12 年。
本页不做什么
① 不做完整时区数据库：纽约、伦敦的夏令时按现行规则回推（美国 3 月第二个周日 — 11 月第一个周日，英国/欧盟 3 月最后一个周日 — 10 月最后一个周日），1970 年前的历史时区变更与各地历史上的夏令时没有纳入；② 不解析自然语言与日期字符串——输入框只接受数字，日期转时间戳请用第二组面板；③ 不做闰秒：Unix 时间戳按 86400 秒一天匀速计算，不含闰秒；④ 本页只做时间换算，不涉及任何吉凶、宜忌之类判断。时间戳是"从 1970-01-01T00:00:00Z 起经过的秒数"，它记录的是一个绝对瞬间，本身不带时区；UTC、北京、东京的读数只是同一个瞬间在不同钟面上的投影。本页所有换算都按这个口径，秒级/毫秒/微秒互转只是乘除 1000，不做任何"本地时间"猜测。
常见问题
时间戳转换怎么算？公式是什么？
只有一条公式：时间戳 = 从 1970-01-01T00:00:00Z 到你那个瞬间经过的秒数；反过来，把这个秒数加回纪元，就是那个瞬间。以本页生成时刻为例：1,793,376,000 秒 = 北京 2026-10-31 00:00:00 = UTC 2026-10-30 16:00:00。手算过程是：1,793,376,000 ÷ 86400 = 20,756 天 …… 余 57,600 秒；从 1970-01-01 起数这么多天（闰年自动多一天）就落在 2026-10-30，余下的 57,600 秒就是 UTC 的 16:00:00。本页上方第一组面板就是这条公式的实现，输入任意时间戳立刻给出 UTC 与北京两个读数。
怎么区分秒级和毫秒级时间戳？
先数位数，再对年份：10 位 = 秒（当下 1,793,376,000 就是 10 位）、13 位 = 毫秒（1,793,376,000,000）、16 位 = 微秒（1,793,376,000,000,000）。同一个瞬间，毫秒级数字正好是秒级的 1000 倍、微秒级是 1000000 倍，所以把 13 位数字末尾去掉三位就回到秒。拿不准时用"年份校验"：把候选数字按秒读，如果落在今天附近，它就是秒级；如果读出 1970 年附近或几万年以后，说明单位选错了——按毫秒读一次通常就对上了。本页第一组面板默认按位数自动识别，也可以在"单位"里手动指定秒 / 毫秒 / 微秒，识别理由会写在结果里。
为什么我算出来总是差 8 小时？
因为北京是 UTC+8，而时间戳本身没有时区。同一个时间戳 1,793,376,000，UTC 读数是 2026-10-30 16:00:00，北京读数是 2026-10-31 00:00:00，两者正好差 8 小时（28800 秒）。最常见的踩坑方式有两种：① 把"北京钟面时间"直接当成 UTC 去算时间戳，结果少了 28800 秒；② 把 10 位时间戳当毫秒读，结果整体缩到 1970 年。判断方法很简单：本页结果里 UTC 与北京永远同时给出，两列相差恰是 8 小时就是对的。看另一个例子：2000 年元旦按 UTC 算是 946684800，按北京时间 0 点算是 946656000，两个都是"2000 年元旦"，差 28800 秒。
北京时间的时间戳怎么算？
先按 UTC 规则算出这个钟面时间的秒数，再减去 28800 秒（8 × 3600）：北京钟面时间 = UTC 钟面时间 + 8 小时，所以同一个钟面数字，北京时间对应的时间戳更小。以"今天 00:00（北京）"为例：时间戳是 1,793,376,000，它的 UTC 读数是 2026-10-30 16:00:00（前一天的 16:00:00）；反过来，今天 00:00 的 UTC 瞬间对应时间戳 1,793,404,800，比北京口径大 28800。本页第二组面板默认就按北京时间解释：选好年月日时分秒，直接给出秒级 / 毫秒级 / 微秒级时间戳与带 +08:00 的 ISO 8601 字符串。要按 UTC 解释，把结果减去 28800 即可。
2038 年问题是什么？离现在还有多久？
32 位有符号整数最大只能表示 2147483647，对应 2038-01-19 03:14:07 UTC（北京 2038-01-19 11:14:07）。再往后走一秒，这个计数器就会溢出并回卷成 −2147483648，也就是 1901-12-13 20:45:52 UTC，程序里的日期会突然"回到过去"。距今还有约 12 年（以 2026 年计）。现在主流服务器早已是 64 位、时间戳用 64 位整数，理论上可用到约 2920 亿年后；但嵌入式设备、老数据库字段（INT 存时间戳）、老协议与老文件格式仍可能是 32 位，所以这个问题没有完全消失。本页锚点表里把 2147483647 与溢出后的 2147483648 两行并排列出，方便对照。
时间戳会重复吗？同一秒里发生两件事怎么办？
在同一单位下不会重复：秒级时间戳每过一秒 +1，是个严格递增的整数，同一个数值只对应一个瞬间。想区分同一秒里的先后，就得换更细的单位——换成毫秒级（13 位）、微秒级（16 位）甚至纳秒级。真正容易让人误以为"重复"的有两种情况：① 单位混用，比如把毫秒级数字 1767196800000 当成秒读成了 1970 年，或反过来把秒级乘了两次 1000；② 夏令时回拨，纽约、伦敦在换季那天凌晨的钟面时间会出现两次（例如 01:30 走两遍），钟面时间重复，但时间戳仍然是两个不同的值。这也是本页在所有地方同时给出 UTC 读数的原因：只要看 UTC，就不会被当地钟面时间绕进去。
两个时间戳相差多少天怎么算？
三步：相减得秒差 → 除以 86400 得天数 → 看要不要算首日。秒差 = 大的 − 小的；天数想要精确小数就除以 86400，想要"整日差"就向下取整；如果要"含首日"口径（两端的那一天都算进去，民俗与天数统计常用），再 +1 天。举例：十亿秒 1000000000 与 32 位上限 2147483647 相差 1,147,483,647 秒 ≈ 13,281 天（精确值 13281.06 天），也就是 13,281 天 1 小时 27 分 27 秒（含首日口径是 13,282 天），约 36.4 年。本页第一组面板的结果卡里就有"与当前时刻相差"一栏，用的正是这套口径。
图解：时间戳、时区与位数
