日期时间转换器

在 Unix 时间戳、JavaScript 毫秒、ISO 8601、ISO 9075、RFC 3339、RFC 7231、Mongo ObjectID 与 Excel 序列号之间互相转换，自动识别输入格式。

把同一个时间点转换成你需要的所有格式。

时间戳格式详解

秒还是毫秒

处理时间戳时最常见的错误就是混淆这两者。Unix 时间戳从 1970-01-01 UTC 起计秒，而 JavaScript 的 Date.now() 计的是毫秒。如果把 Unix 时间戳不乘 1000 直接丢进 Date 构造函数，结果会落在 1970 年 1 月。经验法则是：10 位数是秒，13 位数是毫秒——本工具的自动识别正是这样判断的。

各种标准的区别

  • ISO 8601 是基准标准：2024-01-15T10:30:00.000Z。T 分隔日期与时间，Z 表示 UTC。
  • RFC 3339 是面向互联网协议的 ISO 8601 严格子集，要求显式写出时区偏移，所以用 +00:00 而不是 Z。
  • ISO 9075 是 SQL 标准格式 2024-01-15 10:30:00——用空格代替 T，且不带时区。大多数数据库输出的就是这种。
  • RFC 7231 是 HTTP 日期格式，用于 Date、Expires、Last-Modified 响应头，始终使用 GMT。

两个特殊格式

Mongo ObjectID 共 12 字节，前 4 字节就是以 Unix 秒表示的创建时间，因此每个 ObjectID 内部都自带时间戳。本工具在解码时会把它提取出来；在生成时则将剩余 8 字节补零，而不是伪造机器标识和计数器。

Excel 序列号表示自 1899-12-30 起的天数，小数部分代表当天的时刻。这个看似奇怪的起点，源于 Excel 刻意复现了 Lotus 1-2-3 把 1900 年当作闰年的历史 bug。把 1899-12-30 当作第 0 天，可以让 1900 年 3 月以后的所有日期都对得上，所以本工具采用这个基准。

本质上只是同一个瞬间

无论你输入哪种格式，工具都会先解析成一个 JavaScript Date 对象，再把这同一个瞬间用全部 11 种格式重新渲染出来。所有转换都在浏览器本地完成，数据不会上传。

常见问题

为什么我的 Unix 时间戳显示成 1970 年？
几乎可以肯定是把秒当成毫秒传了。乘以 1000 即可，或者直接把输入格式选为「Unix 秒」，让工具替你处理。
ISO 8601 和 RFC 3339 有什么区别？
RFC 3339 是面向互联网协议的 ISO 8601 严格子集。所有 RFC 3339 日期都是合法的 ISO 8601，反之则不然——RFC 3339 必须写出 +00:00 这样的数字偏移，而 ISO 8601 还允许 Z、周日期和序数日期等写法。
能从 Mongo ObjectID 里取出时间吗？
可以。ObjectID 的前 4 字节（8 个十六进制字符）就是以 Unix 秒表示的创建时间。粘贴 ObjectID，工具会把那个瞬间解码成其余所有格式。
为什么 Excel 的起点是 1899-12-30 而不是 1900-01-01？
Excel 刻意保留了 Lotus 1-2-3 把 1900 年当作闰年的 bug。把起点前移到 1899-12-30 正好抵消由此产生的一天偏差，使 1900 年 3 月以后的日期都能正确换算。
我的数据会上传到服务器吗？
不会。所有解析和格式化都在你的浏览器本地使用标准 Date API 完成，不上传、不记录。