这个工具做什么

把 Unix 时间戳换算成可读的日期时间. 粘贴或输入一个 10 位(秒)或 13 位(毫秒) 的纯数字, 点"转换"即可得到 yyyy-MM-dd HH:mm:ss 格式的结果, 并可一键复制. 输入框里的 1767752074621 就是一个可直接点"转换"试试的真实样例.

输入: 1767752074621        (13 位, 毫秒)
输入: 1767752074           (10 位, 秒)
输出: 2026-01-07 10:14:34  (东八区北京时间, 精确到秒)

怎么用

1. 把日志, 数据库字段或接口返回里的时间戳数字复制进输入框;
2. 点"转换", 结果出现在下方; 点结果右侧的复制图标即可取走;
3. 换下一个值时点"清空", 避免新旧内容混在一起.

Unix 时间戳是什么

Unix 时间戳是从 1970-01-01 00:00:00 UTC(Unix 纪元)开始走过的时长. Java 的 System.currentTimeMillis(), JavaScript 的 Date.now() 返回的都是毫秒值, 所以是 13 位; Linux 的 date +%s, MySQL 的 UNIX_TIMESTAMP() 返回的是秒值, 所以是 10 位. 两者换算只差三个零, 但排查问题时把它们搞混, 就会得到相差几十万年的日期 -- 这是日志时间对不上最常见的原因之一.

各语言里怎么拿到时间戳

• Java: System.currentTimeMillis() 毫秒; Instant.now().getEpochSecond() 秒
• JavaScript: Date.now() 毫秒; Math.floor(Date.now() / 1000) 秒
• MySQL: SELECT UNIX_TIMESTAMP(NOW()) 秒; 反算 FROM_UNIXTIME(1767752074)
• Linux Shell: date +%s 秒; 反算 date -d @1767752074
• Go: time.Now().Unix() 秒; time.Now().UnixMilli() 毫秒

常见问题

10 位和 13 位有区别吗?

有, 但只是精度不同: 10 位按秒解析, 13 位按毫秒解析. 本工具的展示结果统一精确到秒, 所以同一个时刻的 13 位毫秒值和它的 10 位秒值会转出一模一样的字符串, 末尾的毫秒部分被舍弃.

为什么提示"仅支持数值长度10或13"?

工具只接受长度恰好为 10 位或 13 位的数字. 常见触发原因有三个: 时间戳前后带了空格或引号; 复制时把毫秒小数点后的内容或科学计数法(如 1.767752074621E12)一起粘了进来; 或者拿到的其实是 yyyyMMddHHmmss 这类格式化数字而不是时间戳. 前者去掉杂质重新提交, 后者应该直接按字符串读, 不需要转换.

转换结果是哪个时区?

按东八区(北京时间)返回. 时间戳本身是与时区无关的绝对时刻, 同一秒值在 UTC 时区下会显示为早 8 小时. 如果你手上的数据来自 UTC 服务器, 请把结果减 8 小时, 或用命令行 date -u -d @1767752074 对照.

能把"日期时间"转成时间戳吗?

这个页面目前只做了时间戳到日期的单向换算. 反查可以用手边的现成工具: MySQL 里 SELECT UNIX_TIMESTAMP('2026-01-07 10:14:34'), Java 里 LocalDateTime.of(2026,1,7,10,14,34).toInstant(ZoneOffset.ofHours(8)).toEpochMilli(), 浏览器控制台里 new Date('2026-01-07 10:14:34').getTime().

需要注册或付费吗?内容会被怎么处理?

免注册, 免费, 无使用次数限制. 需要注意: 本工具的解析在服务端完成, 你提交的时间戳数值会作为请求参数发送到接口, 只用于这一次换算, 页面没有账号体系, 也不会把结果展示给其他访问者. 含敏感数据的内容请自行评估.

相关工具