13 位时间戳转出来是 55840 年？时间戳转换要先选对单位和时区

时间戳转换出问题，几乎都不是数字本身错了，而是页面上两个下拉框没选对：单位（秒 / 毫秒）和时区。选错之后工具照样输出一个格式完全正确的日期，所以很容易被当成真实结果用下去。

页面开头写的「支持 10 位秒级 / 13 位毫秒级」，指的是两种都能转，不是自动识别位数。默认单位是「秒（s）」，默认时区是 Asia/Shanghai。下面所有数值都是在 宝塔的时间戳转换工具 上一次运行里得到的。

13 位毫秒当秒算，结果就是 55840 年

在默认的「秒（s）」模式下，把毫秒时间戳直接粘进去：

• 输入：1700000000000
• 输出：55840-11-09 06:13:20

原因很直接：这个数字被当成 1.7 万亿秒。1.7×10¹² ÷ 31,557,600 ≈ 53,870 年，1970 + 53,870 ≈ 55840。工具没有做任何「位数像毫秒就自动除 1000」的猜测。

用系统自带的 GNU date 对照，结论一样：

date -u -d @1700000000000 '+%Y-%m-%d %H:%M:%S'
# 55840-11-08 22:13:20

UTC 的 55840-11-08 22:13:20 加 8 小时，正是工具显示的 55840-11-09 06:13:20。也就是说，工具的行为等价于按秒解释输入值。

切到「毫秒（ms）」：同一串数字是 2023-11-15

把左上角的下拉框从「秒（s）」改成「毫秒（ms）」，别的不动，同一串 1700000000000 立刻变成：

• 输出：2023-11-15 06:13:20

这个时刻写成 10 位秒级就是 1700000000，在秒模式下转出来也是 2023-11-15 06:13:20。两个数字差 1000 倍，指的是同一秒。

反过来的坑更隐蔽：在毫秒模式里粘 10 位的 1700000000，结果是 1970-01-21 00:13:20——一个 1970 年的日期。它不像「55840 年」那么刺眼，很容易被当成正常结果放过。

差 8 小时：是时区下拉框，不是算错

时区下拉框默认 Asia/Shanghai，展开后可选一长串 IANA 时区（Asia/Tokyo、America/New_York、Europe/London 等）。同一个时间戳：

时区选择	1793957700 的换算结果
Asia/Shanghai（默认）	2026-11-06 17:35:00
America/New_York	2026-11-06 04:35:00

差 13 小时是因为 11 月的纽约在 EST（UTC−5），而上海是 UTC+8；夏令时期间纽约是 UTC−4，两者相差 12 小时。这不是工具的问题，是所选时区不同。

服务器日志大多是 UTC。同一时刻在服务器上查：

date -u -d @1793957700 '+%Y-%m-%d %H:%M:%S'
# 2026-11-06 09:35:00
TZ=Asia/Shanghai date -d @1793957700 '+%Y-%m-%d %H:%M:%S %Z'
# 2026-11-06 17:35:00 CST

所以「日志时间比实际早 8 小时」通常只说明日志是 UTC 而你按北京时间在读，把下拉框调成和日志一致再转，数字就对上了。

还有一点容易漏：结果字符串本身不带时区后缀。2026-11-06 17:35:00 这行字截图发出去、或者复制进工单，看的人无法知道它是哪个时区的 17:35。转完把时区一起记，别单独传那串日期。

反向转也一样：位数跟着单位走

日期转时间戳用的是同一个单位下拉框。选 2026-11-06 17:35:00：

• 秒模式下输出 1793957700（10 位）
• 毫秒模式下输出 1793957700000（13 位）

接口要哪种位数，就先选哪个单位再复制，它不会同时给两种。需要输出 ISO 8601 或自定义格式（2026-11-06T17:35:00+08:00 这类）时，用 日期格式转换工具 更合适——时间戳转换只给 YYYY-MM-DD HH:mm:ss。

边界值实测：0、负数、2038、非数字

以下都在秒模式（除注明外）下测得：

输入	输出	说明
0	1970-01-01 08:00:00	0 是有效值，按 UTC+8 显示
-1	1970-01-01 07:59:59	负数不拦截，按纪元前计算
2147483647	2038-01-19 11:14:07	32 位有符号整数的上限
2147483648	2038-01-19 11:14:08	越过上限照常换算，无溢出
9999999999	2286-11-21 01:46:39	10 位数字的上限（2286 年），不是整型上限
17000000000（11 位）	2508-09-16 14:13:20	11 位仍按秒处理
170000000000（12 位）	7357-01-31 22:13:20	12 位仍按秒处理
1700000000.5	2023-11-15 06:13:20	小数被截断，输出精确到秒
abc	（空）	不报错，结果框留空

两点值得记住：

1. 位数不是判定依据。11 位、12 位都被当成秒，所以「位数不对」不会触发任何提示，只会给你一个更离谱的年份。
2. 工具能算 2038 之后，不等于你的系统能存。浏览器里的数字是双精度浮点，2147483648 照样算得出来；但把时间戳写进 32 位有符号整数的字段（部分数据库的 int(11)、32 位编译的程序）仍会在 2038-01-19 03:14:07 UTC 溢出，要改成 bigint / 64 位整数。顺带一提，int(11) 里的 11 只是显示宽度，实际仍是 4 字节有符号整数，改成 int(12) 不会扩容。另一条容易混的分界线是 32 位无符号整数（MySQL 的 int unsigned）：上限是 4294967295，对应 2106-02-07 06:28:15 UTC、北京时间 14:28:15，和 9999999999 无关。

用它的顺序：先看位数，再定时区，最后粘贴

输入框没有「转换」按钮，页面写着「输入即触发转换」，粘贴完直接出结果。这也意味着两个下拉框必须在粘贴之前就选好。

1. 看位数：10 位按秒、13 位按毫秒，先把单位下拉框切对。
2. 定时区：日志里是什么时区就选什么；不确定就在服务器上跑一行 date，带 -u 的是 UTC。
3. 再粘贴：结果框和「当前时间戳」那行都带复制按钮，复制时把单位、时区一并记下。

日志里拿到的是毫秒值、又只想在终端看时间，可以直接除：date -u -d @$((1793957700123/1000)) 得到 2026-11-06 09:35:00，和工具在 UTC 下显示的一致。