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

秒精度时间戳（截至 2026 年为 10 位）是 POSIX 系统、Linux 文件元数据和许多数据库使用的原始 Unix 时间标准。毫秒精度时间戳（13 位）被 JavaScript 的 Date.now()、Java 的 System.currentTimeMillis() 以及许多需要更细粒度用于请求计时、性能测量或事件排序的 Web API 使用。微秒精度时间戳（16 位）出现在高频交易系统、科学数据收集以及 Python 的 datetime 对象（具有微秒分辨率）中。关键的实际区别：如果您看到约 1,750,000,000 附近的时间戳，它是秒。如果您看到约 1,750,000,000,000 附近的时间戳，它是毫秒。识别错误导致差 1000 倍会产生向任一方向偏差 56 年的日期——159,362,180,000,000 不是 5044 年，它只是 159,362,180,000 毫秒，大约是 1975 年。我们的工具检测大小并自动应用正确的除数，因此您永远不需要猜测。

为什么转换后的日期看起来比我预期的偏差了一小时？

这几乎总是夏令时（DST）问题，而非转换器的错误。UTC 是连续、均匀的时间尺度，不遵守 DST。然而，您的本地时间在春季向前移动一小时，在秋季向后移动一小时。例如，如果七月在纽约（EDT = UTC-4），代表 UTC 下午 3:00 的时间戳显示为本地上午 11:00。如果您预期中午，您可能在心里应用了冬季偏移（EST = UTC-5）而非夏季偏移。转换器并排显示 UTC 和本地时间，并标注精确的 UTC 偏移（例如 UTC-4 或 UTC-5），因此您可以立即验证正在应用的是哪个偏移。如果偏移对您的位置不正确，请检查计算机的系统时区设置——基于浏览器的工具从您的操作系统获取本地时区，配置不正确的系统时钟或时区将产生意外的本地时间显示。

我可以使用 Unix 时间戳转换器转换 1970 年之前的日期吗？

可以。Unix 时间戳系统支持纪元前日期的负数。1970 年 1 月 1 日 00:00:00 UTC 是时间戳 0。早一秒钟——1969 年 12 月 31 日 23:59:59 UTC——是时间戳 -1。早一天（1969 年 12 月 31 日 00:00:00 UTC）是时间戳 -86400。我们的转换器正确处理回至公元 1000 年 1 月 1 日（时间戳 -30610224000）的负数时间戳，这涵盖了几乎所有历史计算数据。对于早于公元 1000 年的日期，预推公历（将公历回溯扩展到其 1582 年采用之前）引入越来越大的不准确性，应使用专门的历史日期库。1970 年前的时间戳最常出现在家谱数据库、历史档案、遗留银行系统以及从 Unix 纪元标准化前就已运行的系统导入的数据中。

什么是 2038 年问题，我应该担心吗？

2038 年问题（Y2038 或 Y2K38）影响将 Unix 时间戳存储为有符号 32 位整数的系统。在此表示中，最大值是 2,147,483,647，对应 2038 年 1 月 19 日 03:14:07 UTC。下一秒，值溢出到 -2,147,483,648，代表 1901 年 12 月 13 日——一个 136 年的向后跳跃，将导致日期计算、比较和显示灾难性失败。这与 Y2K 问题属于同一类问题，但根因不同。面临风险的系统包括：32 位嵌入式设备（路由器、工业控制器、旧版 IoT 硬件）、为 32 位平台编译的使用 time_t 类型的遗留 C/C++ 程序、旧版 PHP（32 位上 5.6 之前）以及 32 位 MySQL/MariaDB 实例。大多数现代系统——64 位 Linux、macOS、Windows、所有主要云平台、当前编程语言运行时和近期数据库版本——使用 64 位时间戳并且是免疫的（64 位有符号时间戳在 292,277,026,596 年溢出）。如果您维护基础设施，审计任何处理日期的 32 位系统并计划在 2038 年前迁移到 64 位。

什么是 ISO 8601 格式，为什么应该在 API 中用它表示日期？

ISO 8601 是国际标准化组织发布的表示日期和时间的国际标准。格式如下：2026-05-10T15:30:00Z（UTC）或 2026-05-10T15:30:00-04:00（带时区偏移）。它有若干优势使其成为 API 响应和数据交换的最佳选择。它无歧义：与地区格式不同（05/10/2026 可能根据语言环境是 5 月 10 日或 10 月 5 日），ISO 8601 始终遵循 YYYY-MM-DD 顺序，没有文化会颠倒。它作为纯文本可排序：ISO 8601 字符串的字母排序产生时间顺序，使其成为日志文件和数据库索引的理想选择。它时区明确：Z 后缀表示 UTC，像 -04:00 这样的数字偏移清晰指示本地时间关系。它被广泛支持：JSON Schema、OpenAPI、JavaScript 的 Date.parse()、Python 的 datetime.fromisoformat() 和每个主要数据库都可以原生解析 ISO 8601。它用 T 分隔日期和时间，避免了 URL 和查询字符串中空格引起的歧义。出于这些原因，几乎所有现代 API 风格指南（Google、Microsoft、Stripe、GitHub）都推荐使用 ISO 8601 表示日期时间。

不同编程语言如何处理 Unix 时间戳，我应该注意什么？

不同语言以不同单位和类型返回时间戳，混淆它们是常见的错误来源。JavaScript 的 Date.now() 以数字形式返回毫秒——如果您将其传递给期望秒的系统，您的日期将放大 1000 倍（50668 年而非 2026 年）。Python 的 time.time() 以浮点数返回秒，整数部分是秒，小数部分是亚秒精度——当您需要毫秒时，乘以 1,000 并四舍五入。Java 的 System.currentTimeMillis() 以 long 形式返回毫秒。PHP 的 time() 以整数返回秒；microtime() 以浮点数返回秒。Go 的 time.Now().Unix() 返回秒；time.Now().UnixMilli() 返回毫秒。Rust 的 SystemTime 使用自纪元以来的 Duration，具有纳秒精度。最安全的做法：在系统之间发送时间戳时，在 API 规范中明确记录单位（秒、毫秒或微秒），并通过检查其大小来验证传入的时间戳——如果一个应该是"秒"的时间戳是 13 位，拒绝或转换它，而不是静默计算一个 50668 年的日期。

开发者工具精选2026-05-10

如何使用 Unix 时间戳转换器 – 在线纪元时间转日期

计算机不理解"2026 年 5 月 10 日下午 3:30"。它们理解数字——具体来说，是一个从固定参考点开始计数的整秒数（或毫秒数）。那个参考点是 Unix 纪元：1970 年 1 月 1 日 00:00:00 UTC。数字 1751500800 对人类来说不像任何有意义的东西，但对计算机来说，它明确代表一个精确的时刻，与时区、夏令时变化或日历怪癖无关。这种优雅的简单性正是 Unix 时间戳成为软件中主导时间表示的原因：它们出现在 API 响应中（created_at: 1751500800）、数据库时间戳列中、日志文件中（每行前缀纪元值）、身份验证令牌中（JWT 中的 iat 和 exp 声明），以及几乎每个需要记录事件发生时间的系统中。但当您需要调试生产事故、阅读审计日志或验证 API 响应是否包含正确日期时，那些整数时间戳变成了一堵毫无意义的数字墙。我们的免费时间戳转换器立即消除这种摩擦。粘贴任何 Unix 时间戳——无论是秒（10 位）、毫秒（13 位）甚至微秒（16 位）——工具会显示等效的人类可读日期和时间，同时包含 UTC 和您的本地时区。ISO 8601 格式输出（例如 2026-05-10T15:30:00Z）可以直接放入任何 API 文档、测试固件或数据库查询。反向转换同样简单：从日历选择器中选择日期和时间，立即获得对应的 Unix 时间戳。每次计算都在您的浏览器中进行，零服务器通信，工具处理许多转换器遗漏的边缘情况：1970 年前的负数时间戳、32 位系统的 2038 年问题，以及秒、毫秒、微秒精度的自动检测。

schedule

时间戳转换器

免费 · 无需注册

免费试用此工具 →open_in_new

分步指南

粘贴您的 Unix 时间戳或从日历中选择日期

要将时间戳转换为人类可读的日期，将整数粘贴到输入字段。工具根据数字的大小自动检测精度：10 位数字（截至 2026 年约为 1,000,000,000 到 2,000,000,000）被视为秒；13 位数字（约为 1,700,000,000,000 到 1,800,000,000,000）被视为毫秒；16 位数字被视为微秒。这种自动检测消除了"这个时间戳是秒还是毫秒？"的猜测——这个问题在生产系统中造成了无数差 1000 倍的错误。如果您有不寻常格式的时间戳（例如，带小数毫秒的秒数），工具正确解析它并显示包括小数秒在内的精确时间。要将日期转换为时间戳，使用日期和时间选择器选择从公元 1000 年 1 月 1 日到公元 9999 年 12 月 31 日之间的任何日期。调整日期或时间时，等效的 Unix 时间戳立即出现。您还可以点击"使用当前时间"以当前时刻填充选择器，用于为 API 测试请求生成时间戳或检查特定日志条目是多久前创建的。

同时以多种格式阅读转换后的日期

工具以三种互补格式显示转换结果，让您选取所需的内容。首先，人类可读的日期和时间以您的本地时区显示——例如"2026 年 5 月 10 日星期日下午 3:30:00 EDT"——UTC 偏移清晰标注，因此关于显示的是哪个时区没有歧义。其次，UTC 等效值在旁边显示，因为 UTC 是消除时区混淆的通用参考。并排显示让您能立即验证时间戳是否符合预期：如果 API 显示用户在 1751500800 创建，而您的本地显示为下午 3:30 但 UTC 显示为下午 7:30，您就知道时间戳是正确的，差异只是您的时区偏移。第三，ISO 8601 格式字符串出现（例如 2026-05-10T15:30:00-04:00 或 2026-05-10T19:30:00Z 用于 UTC），可直接用于 API、数据库查询或文档。ISO 8601 是日期时间表示的国际标准，是数据交换的最安全格式，因为它明确无歧义、作为纯文本可排序且包含时区信息。相对时间描述——如"3 小时前"、"2 天后"或"上周二"——无需心算即可提供即时的人类上下文。

以您偏好的格式复制输出或在代码中使用

每种输出格式都有自己专用的复制按钮——点击 Unix 时间戳（10 位秒）、毫秒时间戳（13 位）、ISO 8601 字符串或人类可读日期旁边的按钮，将该特定格式复制到剪贴板。这让您能准确获取代码、数据库或文档所需的内容，而无需手动重新格式化任何东西。对于将时间戳转换集成到工作流中的开发者，该工具可作为生成测试数据的快速参考：想测试您的应用如何处理 30 天后的未来事件？选择日期，复制对应的时间戳，将其插入测试数据库。需要验证 JWT 令牌的 exp 声明（过期时间）是否已过？粘贴 exp 时间戳并检查相对时间显示——如果显示"5 分钟后"，令牌仍有效。对于日志分析，粘贴日志文件中的一系列时间戳，以本地时间重建事件时间线，使关联事件与特定用户操作变得容易得多。该工具在编写日期相关代码时也有帮助：它通过让您手动对照已知参考来验证输出，从而确认您的时间戳到日期转换是否正确。

使用技巧与最佳实践

check_circle

以秒为单位的 Unix 时间戳从 2001 年 9 月到大约 2286 年 11 月（跨越 285 年）为 10 位数字。同期内毫秒时间戳为 13 位，直到 2286 年保持不变。如果您的时间戳是 10 位，几乎可以肯定是秒；13 位意味着毫秒；16 位意味着微秒。工具为您自动检测。

check_circle

JavaScript 的 Date.now() 返回毫秒精度的时间戳（13 位）。Python 的 time.time() 返回一个浮点数，具有秒精度和微秒小数部分（例如 1751500800.123456）。了解您的语言返回什么，以避免在与其他系统集成时出现差 1000 倍的错误。

check_circle

始终在数据库中以 UTC 存储时间戳。仅在向用户显示时在表示层转换为本地时间。这一做法可以防止大多数与时区相关的生产错误——夏令时转换、用户跨时区移动以及位于不同地理区域的服务器，当规范数据为 UTC 时都不再是问题。

check_circle

ISO 8601 格式（2026-05-10T15:30:00Z）是 API 响应和数据交换的最安全选择。它人类可读、机器可解析、时区明确（Z = UTC，或像 -04:00 这样的偏移），并且作为纯字符串能正确排序。JSON Schema 和 OpenAPI 都推荐对日期时间字段使用 ISO 8601。

check_circle

2038 年问题影响 32 位有符号整数时间戳：在 2038 年 1 月 19 日 03:14:07 UTC，值达到 2,147,483,647（32 位有符号整数的最大值）并溢出为负数，导致日期跳回 1901 年 12 月。现代 64 位系统是免疫的（它们可以表示 2920 亿年后的未来日期），但嵌入式系统、遗留数据库和旧版 IoT 设备可能仍使用 32 位 time_t。如果您维护在 32 位平台上使用 time_t 的 C/C++ 代码，计划在 2038 年前迁移到 64 位。

check_circle

负数时间戳代表 Unix 纪元（1970 年 1 月 1 日）之前的日期。例如，时间戳 -1 对应 1969 年 12 月 31 日 23:59:59 UTC。转换器正确处理回至公元 1000 年 1 月 1 日的负数时间戳，这对于历史学家、档案工作者以及任何处理早于 Unix 时代的遗留数据的人都很有用。

check_circle

比较来自不同系统的时间戳时，始终检查单位。一个系统可能以秒记录而另一个以毫秒记录。时间戳 1751500800（秒）是 2026 年 5 月 10 日，但 1751500800 被解释为毫秒仅对应 1970 年 1 月 20 日——相差 56 年。如果转换后的日期严重错误，作为第一步调试除以或乘以 1000。

check_circle

关于时区转换：UTC 不遵守夏令时。如果您的本地时间显示比预期偏差一小时，您几乎肯定看到的是 DST 效应。工具并排显示 UTC 和本地时间，因此您可以立即识别 DST 相关的不一致。例如，东部时间在标准时间（EST，十一月到三月）是 UTC-5，但在夏令时（EDT，三月到十一月）是 UTC-4。

常见问题解答

Unix 时间戳（也称为 Unix 时间、纪元时间或 POSIX 时间）是自 1970 年 1 月 1 日 00:00:00 协调世界时（UTC）——Unix 纪元——以来经过的秒数。它不计入闰秒；每天精确按 86,400 秒处理。Unix 时间戳是计算机存储和交换时间的主要方式，因为它们有几个强大的属性：它们是单个整数，仅需 4 或 8 字节存储（比像"2026-05-10T15:30:00+00:00"这样的日期字符串小得多），它们与时区无关（时间戳在世界各地代表同一时刻），它们可简单比较（较早的时间有较小的数字，因此排序和范围查询是简单的比较），算术也直接（加 86,400 前进一天；两个时间戳相减度量经过的秒数）。这些属性使 Unix 时间戳成为数据库、API 响应、日志文件、身份验证令牌、文件系统以及任何需要高效存储、比较或传输日期的系统的理想选择。

Unix 时间戳是软件中时间表示的骨干，但如果没有可靠的转换器，它们是无法理解的。我们的免费工具即时在时间戳和人类可读日期之间转换，自动处理秒/毫秒/微秒，并以 UTC 和您的本地时区显示结果。它离线工作，保持您的数据私密，无需账号。为您的下一次日志分析、API 调试会话或数据库查询加入书签。现在就试试：粘贴任何 Unix 时间戳，看到精确的日期和时间。

免费试用此工具 →open_in_new