AZ Tools

纪元时间转换器 (Unix · NTP · FILETIME · .NET Ticks · Excel · Cocoa)

时间

不同操作系统和应用以'自某个选定零点起经过的秒数(或某单位)'测度时间 ─ 但各自选了不同的零点。Unix 选了 1970-01-01 UTC。NTP 选了 1900-01-01 UTC。Windows NT 取 1601-01-01 UTC,以 100 纳秒为单位计数(FILETIME)。.NET DateTime ticks 从 0001-01-01 起以 100 ns 为单位。经典 Mac OS HFS+ 用 1904-01-01 秒数。Apple Cocoa CFAbsoluteTime 用 2001-01-01 秒数。Microsoft Windows 版 Excel 从 1899-12-30 起按天计数(因为 Lotus 1-2-3 错误地把 1900 当作闰年,Excel 为兼容性沿用此 bug);Mac 版 Excel 从 1904-01-01 起算。还有人类可读格式: ISO 8601 ('2026-06-05T00:00:00.000Z')、RFC 2822 ('Fri, 05 Jun 2026 00:00:00 GMT')。当 SQL Server BIGINT、Windows 事件日志条目、Numbers 导出的 CSV 都描述同一时刻时 ─ 需要互相翻译。本工具一次完成: 左侧选格式、粘入值,其余所有格式即刻按正确的纪元偏移与单位渲染。FILETIME 和 .NET ticks 使用 BigInt 运算 ─ JavaScript 53 位浮点会溢出的远未来日期,精度也能保住。

参考时刻
所有格式
ISO 8601
UTC 的 ISO 8601 日期时间字符串
2026-06-10T04:05:35.539Z
RFC 2822
GMT 的 RFC 2822 / HTTP 日期字符串
Wed, 10 Jun 2026 04:05:35 GMT
Unix(秒)
纪元 1970-01-01 UTC · 秒
1781064335.539
Unix / JS(毫秒)
纪元 1970-01-01 UTC · 毫秒
1781064335539
NTP(秒)
纪元 1900-01-01 UTC · 秒
3990053135.539
Windows FILETIME
纪元 1601-01-01 UTC · 100ns 单位
134255379355390000
.NET Ticks
纪元 0001-01-01 UTC · 100ns 单位
639166611355390000
Mac HFS+(秒)
纪元 1904-01-01 UTC · 秒
3863909135.539
Apple Cocoa
纪元 2001-01-01 UTC · 秒(CFAbsoluteTime)
802757135.539
Excel 1900 序列号
纪元 1899-12-30 · 天数(兼容 Lotus bug)
46183.1705502
Excel 1904 序列号
纪元 1904-01-01 · 天数(Mac Excel)
44721.1705502
转换详情

内部基准值: 1970-01-01 UTC 起的 JavaScript 毫秒(53 位浮点,1970 基准约 ±285 614 年有效)。FILETIME 与 .NET ticks 用 BigInt 运算保持严格整数精度。Excel 1900 使用偏移 25569(1899-12-30 到 1970-01-01) ─ 对 1900-03-01 及之后所有日期都正确,并静默忽略 Lotus 的幻 1900-02-29。ISO 8601 与 RFC 2822 输出始终为 UTC/GMT。

使用方法

  1. 在下拉菜单选择源格式(默认: ISO 8601 当前时间)。
  2. 按该格式输入/粘贴值 ─ 11 种表示即刻更新。
  3. 切换格式下拉以转换: 显示值会按新格式重新填入输入框。
  4. 用预设投入参考时刻: 现在、Unix 纪元(1970)、Y2K、Y2038 问题、NTP 32 位翻滚(2036-02-07)。
  5. 点击任意行的复制按钮把该表示复制到剪贴板。

常见问题

Excel 1900 序列号为何从 1899-12-30 起算而非 1900-01-01?
Lotus 1-2-3 错把 1900 当闰年(其实不是 ─ 1900 ÷ 100 = 19 余 0 但 1900 ÷ 400 ≠ 整数,按格里高利历规则排除)。Microsoft 开发 Excel 时为兼容电子表格直接复制 Lotus 的 bug ─ 所以 Excel 里有一个幻影 1900-02-29。为让偏移对 1900-03-01 后所有日期都干净生效,我们用 25569(1899-12-30 到 1970-01-01 的天数)偏移 ─ 这对所有实际日期都正确。Excel 中 1900-03-01 之前的日期会差一天,但实际中极罕见。
为什么对 FILETIME 和 .NET Ticks 用 BigInt?
FILETIME 从 1601-01-01 UTC 起以 100 ns 计。2100 年附近约 1.6 × 10¹⁷ ─ 远超 Number.MAX_SAFE_INTEGER(约 9 × 10¹⁵)。用普通 JavaScript Number 存储会让低位静默漂移。.NET ticks 同理(2100 年附近约 6.6 × 10¹⁷)。BigInt 是 JS 的任意精度整数类型 ─ 每位都精确保留 ─ 用本工具往返 FILETIME 后位数完全一致。
Y2038 问题是什么? 影响你这里的 Unix 输出吗?
许多遗留 C 程序把 Unix 时间存为有符号 32 位整数,会在 1970 之后 2³¹ − 1 秒时溢出 = 2038-01-19 03:14:07 UTC。本工具把时间存为 JavaScript 毫秒(64 位浮点,1970 基准 ±285 614 年有效),所以 Y2038 在这里不是问题。我们把 Y2038 作为预设暴露,方便看各格式如何表示那个时刻。NTP 因 32 位秒计数器重置,在 2036 年也有自己的翻滚,同样是预设。
为什么 Excel 1900 和 Excel 1904 都暴露?
Windows 版 Excel 基准 1900;Mac 版 Excel(以及最近以前的 Numbers)基准 1904。Windows 分析师和 Mac 分析师邮件互传电子表格在各自应用里看着都正确,但若把底层序列号原样复制就会静默偏移约 4 年。两个格式都暴露便于检测或互转。

相关工具