时间戳
计算在线时间戳转换与日期互转
时间戳是同一个时刻在所有时区下唯一的整数表示，接口参数、日志行、数据库字段里到处都是它。但人读不出 1767196800 是哪一天，机器也不接受「2026 年 1 月 1 日」这种写法，来回转换于是成了调试里最琐碎又最频繁的一步。
最容易出错的不是转换本身，而是单位。同一个时刻既可以写成 10 位的秒数，也可以写成 13 位的毫秒数：Java 和 JavaScript 默认给毫秒，Unix 命令行和多数后端 API 给秒。这里默认按输入长度自动判断，也允许手动锁定为秒或毫秒，用来确认一个可疑的数值究竟属于哪一种。
第二个坑是时区。时间戳本身不含时区信息，同一个数值在 UTC+8 和 UTC 下会渲染成相差 8 小时的两个时间字符串。所以转换结果一次给出本地时区时间和 ISO 8601 的 UTC 时间（末尾带 Z），排查「日志时间和数据库时间对不上」这类问题时，对照这两行通常就能定位。
页面顶部持续刷新当前时间，秒戳、毫秒戳以及 yyyy-MM-dd HH:mm:ss 等常用格式都能直接复制，写测试数据或手动构造请求参数时省掉一次心算。所有计算都在浏览器里执行，你输入的时间戳不会离开本机。
功能一览
- 实时当前时间：三列网格展示秒戳、毫秒戳及六种常用日期格式（含斜杠、紧凑、本地 ISO、UTC ISO），点击即可复制
- 时间戳转日期：输入即转换，可选自动/秒/毫秒单位；结果分两行展示本地时间与 UTC，点击即可复制
- 日期转时间戳：与左侧并排展示，选定日期后即时输出秒级与毫秒级结果，点击复制；窄屏自动改为上下排列
- 单位模式：自动模式按输入长度判断，10 位及以内按秒处理；也可手动锁定为秒或毫秒
- 本地计算：转换逻辑全部在浏览器执行，输入内容不上传，页面加载后断网仍可使用
- 输入自动保留：填过的时间戳与转换结果存在浏览器本地，刷新页面不会丢失
常见问题
- 10 位和 13 位时间戳有什么区别？
- 10 位是秒级时间戳，即 1970-01-01 00:00:00 UTC 以来经过的秒数；13 位是毫秒级，数值是秒级的 1000 倍。Java 的 System.currentTimeMillis()、JavaScript 的 Date.now() 返回 13 位毫秒值，Unix 的 date +%s 和多数后端接口返回 10 位秒值。本工具默认按位数自动区分单位，也可手动锁定核对。
- 时间戳转出来的时间是哪个时区的？
- 转换结果会同时给出两个时间：前面是按你操作系统本地时区格式化的时间（中国大陆即 UTC+8），括号里是 ISO 8601 格式的 UTC 时间，末尾带 Z。反方向的「日期转时间戳」也按本地时区解析你选择的日期，因此在 UTC+8 下选「2026-01-01 00:00:00」得到的秒戳，会比在 UTC 时区下选同样字面时间少 28800 秒。时间戳本身不携带时区信息，时区只影响显示。
- 为什么我的时间戳转出来是 1970 年或者五万年以后？
- 问题出在单位上。把 10 位的秒级时间戳按毫秒解析，1700000000 毫秒只相当于 1970 年 1 月 20 日；反过来把 13 位的毫秒值按秒解析，会算到公元 55828 年。切回「自动」模式即可，它按输入长度判断单位。另外如果你的时间戳带小数点（例如 Python 的 time.time() 返回 1700000000.123），需要先去掉小数部分再输入，本工具只接受纯数字。
- 能转换 1970 年之前的时间吗？
- 「时间戳转日期」只接受纯数字，负号会被判为无效输入，所以负数时间戳暂时无法直接转成日期。反方向可以：「日期转时间戳」的日期选择器允许选 1970 年之前的年份，得到的秒戳和毫秒戳会是负数。如果你的业务里确实存在早于 Unix 纪元的时间，建议在存储层就改用日期类型，而不是负数时间戳。
- 秒级时间戳会在 2038 年溢出吗？
- 溢出只发生在用 32 位有符号整数存储秒级时间戳的系统上，上限是 2038 年 1 月 19 日 03:14:07 UTC。64 位系统、Java 的 long、JavaScript 的 Number 都不受这个限制，本工具基于 JavaScript 的 Date，可表示纪元前后各约 27 万年。真正需要留意的是数据库，如果还在用 MySQL 的 int 存时间戳，应考虑迁移到 bigint。