时间戳转换器 - Unix Timestamp 在线转换

1. 双向转换与单位自动识别

关键认知：**时间戳本身没有时区**，它是一个绝对时刻。「差 8 小时」出在格式化层；「差 1000 倍」出在单位层（把毫秒当秒或反过来）。排查对不上时，先统一单位，再统一 UTC / 本地显示。

1. 时间戳 → 日期：粘贴数字时间戳；默认 auto 按数量级识别秒 / 毫秒 / 微秒 / 纳秒，并显示本地、UTC、ISO 与相对时间。
2. 日期 → 时间戳：选择或输入日期时间，得到常用精度的时间戳。
3. 批量：每行一个时间戳，非法行单独报错，其余行照常转换——适合从日志里抠一列。

2. 开发者必知的时间规则

• 存储永远用 UTC 时间戳，展示层才转本地时区——数据库存本地时间是万恶之源。
• 粗看位数：约 10 位秒、13 位毫秒、16 位微秒、19 位纳秒；边界值请用工具的 auto，不要只靠位数心算。
• 注意 2038 年问题：32 位秒级时间戳将溢出，新系统一律用 64 位。
• 日志对比时区：服务器 UTC、容器可能没设时区、你的电脑东八区——三者混排时先统一基准。

3. JavaScript 处理时间的三个隐坑

其一，Date.getMonth() 返回 0-11——一月份是 0，这个偏差制造过无数线上事故；其二，new Date('2026-01-01') 与 new Date('2026/01/01') 解析不同（ISO 日期串按 UTC 零点，斜杠格式按本地时区），同一段代码跨浏览器/locale 行为漂移；其三，Date.parse 对非标准格式的容忍度因引擎而异， Safari 对 '2026-01-01 00:00:00'（空格分隔）历史上返回 NaN。工程结论：入参解析统一走 ISO 8601 或显式传年月日分量，格式化交给 Intl.DateTimeFormat 而不是手拼字符串。

4. 数据库里的时间戳实践

• MySQL 的 TIMESTAMP 列自带时区换算（连接时区变了读数就变），DATETIME 是字面量存储——「存的是哪个时区的字面量」必须有团队约定。
• PostgreSQL 的 timestamptz 存的是 UTC 绝对时刻、按会话时区显示，语义最接近时间戳本源，新项目优先它。
• 毫秒还是秒要写进字段名或文档（created_at_ms），只写 created_at 的字段是排错时的定时炸弹。

5. 快速心算：时间戳与年代的对应

几个锚点值得记住：10 位数 1600000000 ≈ 2020-09、1700000000 ≈ 2023-11、1800000000 ≈ 2027-01。拿到陌生时间戳先看首位和长度：13 位且以 17-18 开头是 2020 年代的毫秒值，10 位以 1.7-1.8 开头是 2020 年代的秒值。这种粗定位能在日志排查时省掉反复粘贴工具的时间。

6. 微秒 / 纳秒从哪来：Go、Java 与「位数爆炸」

除了大家熟悉的秒与毫秒，现代运行时经常吐出微秒甚至纳秒：Go 的 time.Now().UnixNano()、部分 Java Instant 序列化、追踪系统的高精度 span。数量级大约：秒 < 1e10、毫秒 < 1e13、微秒 < 1e16、再往上按纳秒处理——本工具的 auto 按此划分（曾有「19 位被误判为秒」的坑，已按纳秒修正）。若你确定单位，可在界面手动锁定，避免极端边界值被自动规则分到隔壁档。