时间戳转换器：无需猜测的纪元时间

秒或毫秒：不断发生的错误

十位数字是秒；十三是毫秒。如果出错，日期就会落在 1970 年或几千年后——一旦你看到它，你就能立即识别出这个错误，这正是它值得识别的原因。 JavaScript 的 `Date.now()` 返回毫秒，而大多数服务器语言和数据库存储秒，因此浏览器和 API 之间的边界是通常会犯错误的地方。

                1760000000     → 2025-10-09 09:33:20 UTC   (seconds)
1760000000000  → 2025-10-09 09:33:20 UTC   (milliseconds)
              

UTC 是事实；当地时间是一种演示选择

纪元值是明确的，因为根据定义它是 UTC。当你显示它时，就会出现混乱：同一时刻在每个时区都有不同的挂钟时间，而写着“它发生在下午 3 点”的支持票只有在附加时区时才有用。存储和传输纪元或 ISO 8601 UTC，转换为本地时间进行显示，并始终在人类阅读的任何内容中包含该区域。

时间戳在实际工作中出现的地方

• 日志行 - 最快的方法是在阅读含义之前将纪元列转换为可读日期。
• API 响应 — `created_at`、`expires_at` 和缓存标头，转换后更有用。
• JWT 声明 — `exp` 和 `iat` 是纪元秒，这就是为什么过期检查是一次减法。
• 数据库行——将存储的纪元与现在进行比较是算术；将其与“上周二”进行比较需要转换。

没有时区的时间戳是一个等待读者的错误。打印日期属于具有显式偏移量的 ISO 8601，例如 2025-10-09T09:33:20Z。

2038年的边界

自纪元于 2038 年 1 月 19 日结束以来已签名的 32 位秒。基于该存储构建的系统（包括较旧的 MySQL 列和 32 位 time_t 平台）无法表示较晚的日期，并且故障模式是包装到 1901 而不是错误。如果您正在设计任何打算在未来十年内继续存在的东西，请立即存储 64 位整数或本机日期类型；之后的迁移只会变得更加困难。

在浏览器中双向转换

YamlBox 时间戳转换器接受秒或毫秒，与 ISO 8601 输出并排显示 UTC 和本地解释，并以相反的方式从日期追溯到纪元。它完全在客户端运行，因此生产日志中的时间戳永远不会离开您的计算机。