Unix 时间戳转换器

免费在线 Unix 时间戳转换工具，即时将 epoch 时间戳转日期。自动检测秒/毫秒/微秒，实时时钟，双向转换。数据不出浏览器，无需注册。

无追踪浏览器中运行免费

所有处理均在浏览器本地完成，不向任何服务器发送数据。

当前 Unix 时间戳

Unix 时间戳

快速参考

代码示例

什么是 Unix 时间戳（Epoch 时间）？

Unix 时间戳（也称 Unix 时间、POSIX 时间或纪元时间）是一种将时间点表示为单个整数的系统——即自 Unix 纪元（1970 年 1 月 1 日 00:00:00 UTC）以来经过的秒数。这种简洁的表示方式是互联网上几乎每个操作系统、编程语言、数据库和 API 进行时间追踪的基础。

Unix 纪元选择 1970 年 1 月 1 日并非偶然。Unix 于 1960 年代末在贝尔实验室开发，1970 年是一个方便的整数起点，既足够近以便用合理大小的整数表示常见日期，又是一个干净的整数年份。纪元前的任何时刻都表示为负数：1969 年 12 月 31 日午夜 UTC 是 -86400（纪元前一天，即 86400 秒）。

现代系统通常需要比整秒更精细的时间分辨率。为此，时间戳通常以毫秒（千分之一秒，如 JavaScript 的 Date.now() 或 Java 的 System.currentTimeMillis() 返回的值）或微秒（百万分之一秒，用于 PostgreSQL 等数据库和高频交易系统）表示。您可以通过位数识别精度：10 位表示秒，13 位表示毫秒，16 位表示微秒。本转换器会自动检测您输入的精度。

本转换器可将任意 Unix 时间戳——包括页面顶部实时显示的当前时间戳——即时转换为可读日期。

// Get the current Unix timestamp in JavaScript
const timestampSeconds = Math.floor(Date.now() / 1000);
console.log(timestampSeconds); // → 1741965432

// Milliseconds (native JavaScript)
const timestampMs = Date.now();
console.log(timestampMs); // → 1741965432000

// Convert timestamp back to a Date object
const date = new Date(timestampSeconds * 1000);
console.log(date.toISOString()); // → '2025-03-14T15:37:12.000Z'

// Python equivalent
// import time
// timestamp = int(time.time())  # → 1741965432

核心功能

自动精度检测

自动检测时间戳是秒（10 位）、毫秒（13 位）还是微秒（16 位），无需手动切换模式。

双向转换

将时间戳转换为人类可读日期，或选择任意日期时间立即获得对应的 Unix 时间戳（支持三种精度格式）。

实时纪元时钟

实时显示当前 Unix 时间戳，为您的转换和计算提供准确的参考点。

多格式输出

每次转换同时输出 UTC 时间、本地时区、ISO 8601 格式和人性化相对时间（如「3 天前」）。

100% 浏览器本地处理

所有转换完全在浏览器中使用 JavaScript Date API 完成，不传输任何时间戳、日期或个人数据至服务器。

Unix 时间戳与其他日期格式对比

ISO 8601

2025-03-14T15:37:12Z

既人类可读又可按字典序排序。数据交换和 API 的标准格式。当人类可读性重要时，优先于 Unix 时间戳。

RFC 2822

Fri, 14 Mar 2025 15:37:12 +0000

人类可读但不可排序。主要用于电子邮件头（Date 字段）。比 ISO 8601 和 Unix 时间戳更冗长。

人类可读日期

2025 年 3 月 14 日下午 3:37

对终端用户最可读，但不可排序，也不适合程序化使用。最好保留用于 UI 显示层。

转换示例

标准 Unix 时间戳（秒）

1741965432

2025-03-14T15:37:12Z

10 位秒级时间戳——Unix/Linux 系统、Unix API、JWT 令牌和服务器日志最常用的格式。这个值对应 2025 年圆周率日 15:37:12 UTC。

千年虫时间戳——2000 年 1 月 1 日

946684800

2000-01-01T00:00:00Z

Y2K 时刻的 Unix 时间戳：自 Unix 纪元起恰好经过 946,684,800 秒。这是一个有用的校验值——如果转换器对此输入输出 2000 年 1 月 1 日，则工作正常。

负时间戳（纪元前）

-86400

1969-12-31T00:00:00Z

负 Unix 时间戳表示 1970 年 1 月 1 日之前的日期。-86400 是纪元前恰好一天（86400 秒），对应 1969 年 12 月 31 日午夜 UTC。

毫秒时间戳（13 位）

1741965432000

2025-03-14T15:37:12.000Z

13 位毫秒时间戳——JavaScript 的 Date.now()、Java 的 System.currentTimeMillis() 和大多数现代 REST API 使用的原生格式。自动检测器识别 13 位长度并正确解析为毫秒。

如何将 Unix 时间戳转换为日期

1

选择转换方向

选择「时间戳 → 日期」将 Unix 时间戳解码为人类可读日期，或选择「日期 → 时间戳」将日历日期转换为 Unix 时间戳。
2

输入您的值

粘贴或输入 Unix 时间戳（如 1741965432 或 1741965432000），工具自动识别是秒、毫秒还是微秒。日期转时间戳时，使用日期选择器选择年、月、日、时、分、秒。
3

复制转换结果

立即查看 UTC、本地时间、ISO 8601 和相对时间的转换结果。点击任意格式旁的「复制」按钮将其直接复制到剪贴板。

常见使用场景

API 开发与调试: 解码 API 响应、JWT 令牌载荷（iat、exp、nbf 声明）、Webhook 事件数据和日志条目中的不透明时间戳。即时验证认证令牌是否过期或事件发生时间。
数据库时间戳存储与查询: 在编写数据库查询、检查存储记录或验证 WHERE 子句中的日期范围过滤器是否正确指定时，在 Unix 时间戳和人类可读日期之间进行转换。
日志文件分析与关联: 许多系统和应用日志将事件记录为 Unix 时间戳。将可疑日志条目转换为人类可读时间，以关联多个服务的事件、识别攻击窗口或精确定位错误发生时刻。
JWT 令牌过期验证: JSON Web 令牌在载荷中将 iat（签发时间）、exp（过期时间）和 nbf（生效时间）编码为 Unix 时间戳。直接粘贴这些值以验证令牌有效期窗口，无需手动计算纪元数学。
定时任务调度: 通过将建议的运行时间转换为时间戳再转回，验证 cron 任务调度、定时任务和基于时间的触发器与预期执行窗口是否对齐。
跨时区日期协调: Unix 时间戳本质上与时区无关。在协调不同时区团队的日期和截止日期时，使用本转换器建立共享参考点，确认任意本地时间的 UTC 等价值。

技术参考

Unix 时间戳定义: Unix 时间戳是自 Unix 纪元（1970 年 1 月 1 日 00:00:00 UTC）以来经过的整数秒数。该值与观察者的本地时区无关，使其成为存储和比较时间的理想的时区中立表示方式。
32 位有符号整数最大值: 有符号 32 位整数的最大值为 2,147,483,647。作为 Unix 时间戳，对应 2038 年 1 月 19 日 03:14:07 UTC。以 32 位有符号整数存储时间戳的系统将在此时溢出——即著名的「2038 年问题」。
JavaScript 使用毫秒: JavaScript 的 Date.now() 和 new Date().getTime() 返回自纪元以来的毫秒数，而非秒数，产生 13 位数字。转换为标准 Unix 时间戳（秒）需除以 1000 并取整：Math.floor(Date.now() / 1000)。
负时间戳表示纪元前日期: Unix 时间戳可以为负数，表示 1970 年 1 月 1 日之前的日期。例如 -86400 表示 1969 年 12 月 31 日 00:00:00 UTC。有符号 64 位时间戳的范围约为纪元前后各 2920 亿年。
Unix 时间不计闰秒: Unix 时间假设每天恰好有 86400 秒（24 × 60 × 60）。实际上，IERS 会偶尔插入闰秒以保持 UTC 与地球自转同步。这意味着 Unix 时间相对于 TAI（国际原子时）并非完全线性，但对绝大多数应用来说此差异无关紧要。

时间戳处理最佳实践

始终以 UTC 存储时间戳: 以 UTC（或 Unix 时间戳）存储时间，仅在显示层转换为本地时间。在数据库中混用时区是常见的 bug 来源，尤其在夏令时切换时难以排查。
现代 API 使用毫秒精度: 大多数现代 API、JavaScript 环境和数据库使用毫秒（13 位时间戳）而非秒（10 位）。集成外部系统时请确认预期精度——将毫秒时间戳传给期望秒的函数会产生约 11000 年后的日期。
警惕 2038 年问题: 以 32 位有符号整数存储 Unix 时间戳的系统将在 2038 年 1 月 19 日 03:14:07 UTC 溢出。审计遗留系统中的 32 位时间戳字段并迁移到 64 位整数或 ISO 8601 字符串。
安全场景不依赖客户端时钟: 客户端设备时钟可被随意设置。对于 JWT 过期检查、会话超时或速率限制等安全敏感逻辑，始终在服务端使用可信时间源验证时间戳。
人机交互使用 ISO 8601: 当需要既可机器解析又人类可读的格式时（如日志文件、配置文件或 API 响应），ISO 8601（如 2025-03-14T15:37:12Z）是最佳选择。它可按字典序排序、无歧义，且几乎所有现代解析器都支持。

常见问题

Unix 时间为什么从 1970 年 1 月 1 日开始？

Unix 纪元日期 1970 年 1 月 1 日是贝尔实验室 Unix 开发者在 1960 年代末选择的一个方便的整数起点，既足够近以便常见日期用合理大小的整数表示，又是一个干净的整数年份。当时时间戳以 32 位整数存储，因此纪元需要足够靠近当代。1970 年只是 Unix 系统开发开始后的一个干净整数年份，并无深刻的技术意义。其他系统选择了不同的纪元：经典 Macintosh 工具箱使用 1904 年 1 月 1 日；Windows NT 使用 1601 年 1 月 1 日；GPS 时间从 1980 年 1 月 6 日开始。每个都反映了选择它的系统的时代和设计约束。 Unix 纪元能够保持下来，是因为 Unix 成为了计算领域的主流操作系统，每种主要编程语言、数据库和操作系统最终都采用 Unix 时间作为表示机器可读时间戳的通用标准。今天，Unix 纪元实际上已成为计算中的通用常数，被从 Linux 内核到 JavaScript 引擎再到 SQL 数据库的每个主要平台所认可。

什么是 2038 年问题？

2038 年问题（也称 Y2K38 或「纪元末日」）是一个将影响以有符号 32 位整数存储 Unix 时间戳的系统的计算问题。有符号 32 位整数的最大值为 2,147,483,647，作为 Unix 时间戳对应 2038 年 1 月 19 日 03:14:07 UTC。一秒后，计数器将溢出并回绕到最大负值，对应 1901 年 12 月 13 日——导致这些系统将未来日期解释为遥远的过去。解决方案很简单：将时间戳存储迁移到 64 位有符号整数。64 位时间戳可表示纪元前后约 2920 亿年的日期。大多数现代操作系统、编程语言和数据库内部已使用 64 位时间戳。风险在于遗留代码、嵌入式系统、仍在生产中的 32 位操作系统、文件系统元数据（如 FAT32 的时间戳字段）以及定义为 INT 而非 BIGINT 的数据库列。开发者应立即审计系统。从 32 位到 64 位时间戳的迁移必须在 2038 年前完成，而对于有长期记录（房贷、基础设施资产、法律文件）的系统，受影响字段输入未来日期时可能会更早遇到这个问题。

秒、毫秒和微秒时间戳有什么区别？

Unix 时间戳有三种常见精度，可通过位数区分： **秒（10 位）**：最原始也最常见的 Unix 时间戳格式。`1741965432` 表示特定的某一秒。用于：Unix/Linux 系统调用（time()）、大多数 Unix 工具、JWT 令牌（iat、exp 声明）、HTTP 头（Last-Modified）和许多 REST API。当前时间戳约为 10 位数字。 **毫秒（13 位）**：千分之一秒精度。`1741965432000` 与上面相同时刻，乘以 1000。用于：JavaScript 的 Date.now()、Java 的 System.currentTimeMillis()、Node.js、大多数现代 JavaScript/TypeScript API、Redis 和许多数据库客户端。 **微秒（16 位）**：百万分之一秒精度。`1741965432000000` 与上面相同时刻，乘以 1,000,000。用于：PostgreSQL 的 TIMESTAMP 和 TIMESTAMPTZ 类型、高频交易系统和网络数据包分析工具。最常见的错误是混用精度——例如将毫秒时间戳传给期望秒的函数，会产生约 11574 年后的日期。始终查阅您使用的 API 或系统的文档以确认预期精度。

Unix 时间计入闰秒吗？

不计入——Unix 时间不计入闰秒，这是其在精密计时应用中的已知局限性。闰秒由国际地球自转和参考系服务（IERS）偶尔插入，以保持 UTC 与地球略微不规则的自转同步。截至 2026 年，自 1972 年首次引入以来已插入 27 个闰秒。 Unix 时间假设每天恰好有 86400 秒（24 × 60 × 60）。当插入闰秒时，现实世界有一秒是 Unix 时间忽略的。不同操作系统处理方式不同：Linux 传统上在插入点前后通过略微减慢时钟来「涂抹」闰秒（Google 的方法）；某些系统在 23:59:60 UTC 复制该秒；另一些则简单跳过调整让时钟漂移。对于绝大多数软件应用——Web 服务、API、数据库、业务逻辑——50 多年来累积约 27 秒的闰秒差异完全无关紧要。这对任何面向人类的应用都是不可察觉的差异。

Unix 时间戳可以为负数吗？

可以，Unix 时间戳可以为负数，负时间戳是表示 Unix 纪元（1970 年 1 月 1 日 00:00:00 UTC）之前日期的合法且明确定义的方式。纪元前的每一秒对应从零开始递减 1。例如，-1 表示 1969 年 12 月 31 日 23:59:59 UTC；-86400 表示 1969 年 12 月 31 日 00:00:00 UTC（纪元前恰好一天）；-2208988800 表示 1900 年 1 月 1 日 00:00:00 UTC。大多数现代编程语言和操作系统支持负时间戳。Python 的 datetime.fromtimestamp(-86400) 正确返回 1969 年 12 月 31 日。JavaScript 的 new Date(-86400 * 1000) 正确渲染同一日期。PostgreSQL 以 8 字节整数存储时间戳，正确处理纪元前数千年的日期。但对于历史日期（1970 年以前的任何日期），通常更安全的做法是以 ISO 8601 字符串或数据库原生日期类型存储，而非依赖负 Unix 时间戳的可移植性。本转换器正确处理负时间戳并显示对应的纪元前日期。

如何在 JavaScript、Python 或其他语言中获取当前 Unix 时间戳？

在每种主要编程语言中获取当前 Unix 时间戳都很简单： JavaScript：Math.floor(Date.now() / 1000)（秒）或 Date.now()（毫秒） Python：import time; int(time.time())（秒） Go：time.Now().Unix()（秒）或 time.Now().UnixMilli()（毫秒） Java：System.currentTimeMillis() / 1000L（秒）或 Instant.now().getEpochSecond() PHP：time()（秒） Ruby：Time.now.to_i（秒） Bash：date +%s（秒）最重要的是记住 JavaScript 原生使用毫秒，而几乎所有其他语言默认使用秒。始终明确说明您使用的精度，并在 API 契约中记录，以防止集成 bug。

如何将 epoch 时间转换为可读日期？

有三种快捷方式可以将 epoch 时间（Unix 时间戳）转换为人类可读日期： **1. 使用本在线转换器（最快）** 将 epoch 时间戳粘贴到上方输入框。工具自动检测秒、毫秒或微秒精度，即时显示 UTC、本地时区、ISO 8601 和相对时间格式的结果。点击复制即可获取任意格式。 **2. 使用代码** JavaScript：`new Date(1741965432 * 1000).toISOString()` 返回 `'2025-03-14T15:37:12.000Z'`。Python：`from datetime import datetime, UTC; datetime.fromtimestamp(1741965432, UTC)` 返回相同结果。注意 JavaScript 使用毫秒而 Python 使用秒——这是最常见的转换 bug 来源。 **3. 使用命令行** Linux：`date -d @1741965432`。macOS：`date -r 1741965432`。Windows PowerShell：`[DateTimeOffset]::FromUnixTimeSeconds(1741965432).DateTime`。三种方法产生相同结果。当你只需要快速答案而不想打开终端或编写代码时，上方的在线转换器是最快的选择。

当前的 Unix 时间戳是多少？

当前 Unix 时间戳显示在本页面顶部的实时时钟中，每秒更新一次。Unix 时间戳就是自 1970 年 1 月 1 日 00:00:00 UTC 以来的秒数，每秒精确递增 1。编程获取当前时间戳： - **JavaScript**：`Math.floor(Date.now() / 1000)`（秒）或 `Date.now()`（毫秒） - **Python**：`import time; int(time.time())` - **Bash**：`date +%s` 截至 2026 年，当前 Unix 时间戳在 17.7 亿范围内（10 位数字）。它将在 2033 年左右达到 20 亿，32 位系统的最大值 2,147,483,647 将在 2038 年 1 月 19 日 03:14:07 UTC 到达——即所谓的「2038 年问题」。收藏本页面，随时一键查看当前 epoch 时间。