Unix时间戳转换器

介绍

Unix 时间戳（或称纪元时间）是电脑表示时间的标准方式：一个从 1970 年 1 月 1 日 UTC 午夜开始计算秒数的单一整数（不含闰秒）。它出现在数据库记录、API 回应、JWT 权杖、日志文件、Cron 调度和缓存过期标头中。机器可以实时读取这些整数，但人类需要将它们转换为日历日期和时钟时间——而且通常需要同时转换为多种格式。

Unix 时间戳转换器为开发人员、系统管理员和安全分析师而设计，他们需要从日志中解码时间戳、验证权杖到期时间、跨时区调度 Cron 工作，或快速查找历史或未来的纪元值。此工具分为两个独立区块：

• 区块 A（Unix 时间戳 → 日期与时间）：输入数值时间戳，即可看到以 21 种日期和时间格式呈现的结果，按标准家族分类。
• 区块 B（日期与时间 → Unix 时间戳）：选择日历日期、时间和时区偏移量，即可获得等效的时间戳（以秒、毫秒和微秒表示）。

两个区块都有自己的时区选择器，因此您可以在一个方向使用 UTC，在另一个方向使用自订偏移量，而不会互相干扰。

使用场景

Unix 时间戳转换是开发、维运和安全工作中反复出现的需求。了解这些场景有助于您将该工具集成到工作流程中。

调试日志和错误报告

应用程序日志、数据库日志和错误追踪服务通常将时间戳记录为 Unix 纪元整数。在调查事件时，将时间戳粘贴到区块 A 中，即可查看多种格式的人类可读时间——用于 HTTP 标头关联的 RFC 1123Z、用于 JSON 承载的 ISO 8601，以及用于时效性评估的相对时间。

API 集成和令牌验证

JWT、OAuth 令牌和 API 速率限制标头经常使用 Unix 时间戳来表示过期时间（exp）、签发时间（iat）和重置窗口。使用转换器验证令牌是否仍然有效，检查其相对于当前时区的签发时间，并确认您的本地时钟与服务器的纪元时间一致。

Cron 任务和调度任务规划

在配置 Cron 任务、计划数据库备份或 CI/CD 流水线触发器时，您通常需要将时钟时间表示为 Unix 时间戳。区块 B 让您选择日期、时间和时区，然后输出准确的纪元值——无需心算或时区换算。

多时区协作

分布在多个时区的团队共享日志片段、部署窗口和事件时间线。将 Unix 时间戳粘贴到区块 A 中，并在 UTC、本地和自订时区之间切换，可以揭示同一时刻在每个团队成员本地时间中的显示效果——消除了时区转换字符串带来的歧义。

运作原理

Unix 时间从纪元（1970 年 1 月 1 日 00:00:00 UTC）开始计算秒数。每一次计数正好增加一秒。由于它以 UTC 为锚点，Unix 时间戳在全球任何地方都代表同一个瞬间——只有在将其呈现为人类可读字符串时，时区才有意义。

此工具使用浏览器原生的 JavaScript Date 对象进行所有转换。每个 Date 在内部将时间保存为单一数字：自 Unix 纪元以来的毫秒数。当您输入时间戳时，工具会创建一个 Date 并根据激活的时区选择器读取其 UTC 或本地属性。当您输入日历日期和时间时，工具会计算与纪元的差异，并根据指定的时区偏移量进行调整。

各生态系统中的时间戳单位

不同平台和语言使用不同的纪元单位。工具的单位选择器让您比对来源的精确度：

此工具会将您的输入内部转换为秒。如果您粘贴来自 JavaScript 的 Date.now() 的 13 位数值，请将单位设为毫秒，工具会处理换算。

时区与夏令时间

Unix 时间戳始终代表相同的物理瞬间。每个区块中的时区选择器只会改变该瞬间的显示或解读方式。

• Relative：请求发生至今多久——这一列会对照你目前的时钟实时更新，每次开页数值都不同
• 本地模式：使用您浏览器的系统时区，包括自动的夏令时间调整。
• 自订模式：-12:00 到 +14:00 之间的数值 UTC 偏移量。工具会直接应用此偏移量，不进行任何夏令时间修正——它会将您的偏移量视为固定的时钟时间。

当夏令时间生效时，本地时区偏移量会改变。在本地模式下显示的相同时间戳可能会显示与上个月不同的小时。这是正常现象：时间戳本身相同，但当地时钟惯例改变了。

对于在地化格式的行（Locale、Locale Date、Locale Time），工具会同时尊重所选的时区和浏览器的语言设置。如果您选择 UTC 模式，toLocaleString 会收到 { timeZone: 'UTC' }，确保在地化格式使用正确的时区。

使用方法

区块 A — 时间戳转日期与时间

1. 在输入字段中输入 Unix 时间戳（仅数字，1970 年前可选负号）。
2. 选择输入精确度：秒、毫秒或微秒。
3. 选择时区：UTC、本地（您的系统时区）或自订（以半小时为间隔输入 -12 到 +14 之间的偏移量）。
4. 查看结果——21 行日期和时间格式会实时更新。

区块 B — 日期与时间转时间戳

1. 直接输入年份。使用下拉菜单选择月份、日期、小时、分钟和秒。
2. 从 UTC/GMT 选择器中选择时区：本地符合您的系统时区；像 UTC+8 这样的数值条目会将输入视为该区域的时钟时间。
3. 时间戳结果会立即以秒、毫秒、微秒、十六进位和相对时间显示。

两个区块独立运作。变更区块 A 不会影响区块 B，反之亦然。这让您可以并排比较时间戳，或在探索不同格式时锁定参考值。

教程

情境 1：从服务器日志解码时间戳

您的应用程序日志显示时间戳 1742345678——一次失败的 API 调用。您需要确切知道它发生的时间，并检查 HTTP 日期格式以与 HTTP 回应标头进行关联。

1. 打开 Unix 时间戳转换器。
2. 在区块 A 的输入字段中输入 1742345678。
3. 结果显示 21 行格式，包括：
   • @ 格式：3/19/2025 @ 12:54:38 AM UTC（快速浏览的人类可读格式）
   • RFC 1123Z：Wed, 19 Mar 2025 00:54:38 +0000（HTTP 日期标准，对应 Date 和 Last-Modified 标头）

• Relative：请求发生至今多久——这一列会对照你目前的时钟实时更新，每次开页数值都不同

4. 将时区切换为本地，查看在您自己的时区中是什么时间。

情境 2：在特定时间调度 Cron 工作

您需要在 2026 年 6 月 15 日美国东部时间凌晨 3:30 运行一个 Cron 工作。美国东部夏令时间在 6 月是 UTC-4。

1. 在区块 B 中，将日期设为 2026 年 6 月 15 日，时间设为 03:30:00。
2. 将 UTC/GMT 选择器设为 `UTC+4（EDT 是 UTC-4，因此输入 -4）。
3. 读取秒值——这就是您的 Cron 时间戳。Hex 和 Relative 行也会更新，同时为您提供机器可读和人类可读的参考信息。

专业提示

格式使用场景

每种输出格式都有特定的用途。以下说明何时使用每种格式：

各语言实作

在您选择的语言中取得目前的 Unix 时间戳：

// Go
time.Now().Unix()      // 秒
time.Now().UnixMilli() // 毫秒（Go 1.17+）

// JavaScript
Math.floor(Date.now() / 1000) // 秒
Date.now()                     // 毫秒

// PHP
time();              // 秒
intval(microtime(true) * 1000); // 毫秒

# Python
import time; int(time.time())         # 秒
import time; int(time.time() * 1000)  # 毫秒

通用提示

• 1970 年之前的时间戳：输入负数值。1960 年 12 月 1 日 00:00:00 UTC 为 -286329600。
• 十六进位输入：十六进位值（含或不含 0x 前缀）会自动解析——输入 0x67DA15CE 即可查看十进位等效值。
• 比较时区：将区块 A 的时区设为 UTC，并将区块 B 的时区设为本地，即可查看同一个时间点在两者中的显示差异。

常见错误

Unix 时间戳概念简单，但很容易用错。以下是最常见的陷阱。

秒与毫秒混淆

这是最常犯的错误。10 位数（如 1712345678）是秒；13 位数（如 1712345678000）是毫秒。将毫秒值粘贴到秒模式转换器中，会得出一个未来几十年的日期（例如距今 54382 年）。在转换之前，务必检查数字位数。

在反向转换中忽略时区

将日期和时间转换为 Unix 时间戳（区块 B）时，所选时区非常重要。输入 2026-06-15 03:30:00 时，选择 UTC 与选择 UTC+8 得到的时间戳不同——正好相差 8 小时。每个结果整数对于各自的解释都是正确的，但如果您忘记设置时区，输出将与接收系统的预期不符。

假设本地时间与服务器时间一致

从服务器日志解码时间戳时，该时间戳已经是 UTC 格式——时区仅影响其显示方式。将区块 A 切换到本地模式会改变显示的时间，但不会改变底层的时刻。如果输出看起来不正确，请先检查时区选择器，而不是时间戳值。

为十六进位或相对值使用错误的单位

十六进位和相对时间输出源自相同的内部转换。在单位设为秒的情况下输入毫秒时间戳，会产生代表不同时刻的十六进位值。始终确认单位选择器与来源数据的精确度匹配。

替代方案

数据隐私

Unix 时间戳转换器在您的浏览器中完成所有转换处理。您输入的任何时间戳、日期或时区值都不会传输到任何服务器、保存在任何数据库中或记录在任何系统中。

所有转换均使用浏览器原生的 JavaScript Date 对象在内存中运行。此工具页面不包含任何分析脚本、追踪像素或第三方嵌入。不会创建或读取任何 Cookie、localStorage 或 sessionStorage 条目。

初始页面加载后，转换器可完全脱机运行——您可以断开互联网连接并继续不间断地转换时间戳。您可以透过在飞行模式下使用该工具或检查浏览器开发者工具中的网络活动来验证这一点。

故障排除

技术规格

• 转换引擎：JavaScript Date 对象（ECMAScript 标准）
• 时间戳范围：完整的 JavaScript 数值范围（±9 千兆秒，涵盖数十亿年）
• 支持的输入：十进位整数、负数值（1970 年之前）
• 输入精确度：秒、毫秒或微秒（可设置）
• 时区支持：UTC、本地（浏览器系统）、自订 GMT 偏移量（-12 到 +14，以 0.5 小时为间隔）；每个区块独立设置

21 种格式家族

格式族谱

此工具中的日期和时间格式源自四个谱系：

• RFC 822（1982 年）定义了原始的电子邮件日期格式，使用 2 位数年份。RFC 1123（1989 年）以 4 位数年份取代了它。RFC 1123Z 是相同的格式，但使用数值时区偏移量（+0000）代替字母缩写（UTC）。这些共同涵盖了 HTTP 标头（1123Z）和电子邮件格式（822）。
• ISO 8601（1988 年）创建了日期和时间表示的国际标准。RFC 3339（2002 年）为互联网使用设置了 ISO 8601 的规范配置，添加了 UTC 必须使用 Z 等要求。大多数现代 API 会选择这两者之一。
• Go 时间常数（ANSIC、UnixDate、RubyDate 等）是 Go 标准库内置的便利布局。它们反映了 POSIX 惯例（ctime 输出）、RFC 标准和 Go 专属的便利形式（DateOnly、Kitchen、Stamp）。
• 在地化格式使用浏览器的 Intl.DateTimeFormat API，该 API 遵循 Unicode 通用在地化数据保存库（CLDR）。确切的输出取决于用户的浏览器语言设置。

兼容性

• 浏览器：Chrome 90+、Firefox 90+、Safari 15+、Edge 90+
• 依赖项目：无——纯 JavaScript，零第三方函数库
• 数据处理：100% 客户端处理——零网络请求

功能特色

• Unix时间戳与可读日期的双向转换
• 实时显示当前Unix时间戳并自动更新
• 多种输出格式：UTC、本地时间、ISO 8601、十六进位和相对时间
• 自订时区偏移支持，实现日期到时间戳的精确转换
• 客户端处理 — 不会向任何服务器发送数据

常见问题