Unix 时间戳与日期时间互转

功能

• 实时显示当前时间戳（秒与毫秒并列），可暂停、可一键填入输入框
• 两个方向各自成块：时间戳 → 日期时间、日期时间 → 时间戳
• 日期时间可以用原生日历控件挑，也可以直接粘贴 2026-09-18 15:30:45 这类文本
• 秒与毫秒自动识别，也能手动指定
• 二十个常用时区可选，含印度 +05:30、澳洲 +10:30 这类非整小时偏移
• 时区偏移按所算的那一刻取值，夏令时与历史规则变更都不会差一小时
• 夏令时跳过的钟点直接报错、重复的钟点两条都给，不做静默平移
• 结果逐行给出秒、毫秒、所选时区时间、UTC、ISO 8601、RFC 2822，每行单独可复制
• 批量转换：每行一条，时间戳与日期时间可混写，一行出错不影响其余行
• 批量结果可复制为 TSV 或下载 CSV

使用方法

1. 要当前时间戳？直接点顶部那个数字，它会填进输入框
2. 时间戳转日期：把时间戳粘进第一个面板，选好单位与时区
3. 日期时间转时间戳：用日历挑，或把日期时间粘进文本框
4. 点任意一行右侧的「复制」单独取走那一项
5. 要一次转很多条？切到「批量转换」，每行一条

常见问题

时区是怎么算的？准吗？

按浏览器内置的 IANA 时区数据库计算，也就是说夏令时的起止日期、以及历史上改过时区规则的国家（例如莫斯科 2011 年改成常年 UTC+4、2014 年又改回 UTC+3）都会按所算的那一刻取正确的规则，不是查一张写死的偏移表。下拉里给的是二十个常用时区，而不是完整的四百多个 —— 一长串冷门项只会让人找不到。

拿不准数据属于哪个时区怎么办？

按 UTC 算。时区选错的后果是结果整体偏几个小时，而那种偏差在界面上看不出来 —— 时间照样是一个格式正确的日期。所以当你不确定服务端日志用的是哪个时区时，先按 UTC 换算，再自行加减偏移，比拼一个「大概是吧」的时区可靠。

夏令时那两天的时刻怎么算？

夏令时开始那天有一段钟点在该时区根本不存在（比如纽约 2026-03-08 的 02:30），工具会直接报错并说明被跳过的是哪一段，而不是悄悄挪到 01:30 或 03:30 —— 挪出来的时间戳看着正常，实际差一小时。夏令时结束那天则有一段钟点出现两次（比如纽约 2026-11-01 的 01:30），工具会把两个时间戳都列出来，默认取较早的那个。

为什么我输入的日期格式不被接受？

本工具只认固定几种写法（2026-09-18、2026-09-18 15:30、2026-09-18T15:30:45），因为 JavaScript 的 new Date(字符串) 在不同浏览器上的解析规则并不一致 —— 同一个输入可能被解析成不同的日期，且不报错。像 09/18/2026 这种既能当美式又能当欧式读的写法，工具一律拒绝，以免给出「看着对但其实错」的结果。不存在的日期（如 2 月 30 日）同样直接报错，不做静默纠正。

2038 年问题是什么？

一些用 32 位有符号整数存秒数的系统会在 2038-01-19 03:14:07 UTC 溢出成负数。本工具内部按毫秒计算，能表示到公元 27 万年左右，所以查询 2038 年之后的时间没有问题。

输入 19 位数字为什么报超出范围？

19 位数字更可能是雪花算法 ID 或数据库主键，而不是时间戳 —— 毫秒时间戳目前只有 13 位。这类 ID 的转换请用进制转换工具。

数据会上传到服务器吗？

不会。全部换算在浏览器内存里完成，页面不发送任何请求，断网也能照常用。