DEV

日期转 Epoch — 将日期转换为 Unix 时间戳

将日期和时间转换为 Unix 时间戳（epoch 秒）。支持毫秒和纳秒精度，全部在浏览器中完成。无上传、无限制。

● 本地运行 · 在您的标签页中生成页面加载以来工具发出的网络请求：0 次

Date to Epoch

Convert dates and times to Unix epoch timestamps. Works entirely in your browser — no uploads.

Enter date

您可能还需要

排序行 MD5 哈希 UUID 生成器 JSON 转 CSV Base64 编码 PDF 拆分 HAR 转 cURL TOML 工具 .env 助手 MsgPack 检查器 PDF 压缩 PDF 转 EPUB

打开转换器

Unix 时间戳是计算机世界里时间的通用语言。每个数据库、每个日志文件、每个 API、每个调度器都在用它。它们与时区无关（同一个数字在地球任何地方都对应同一瞬间）、排序天然正确（数字更大的永远更晚）、可以无损往返（转成数字存起来、读出来再转回日期，信息不丢）、并且有唯一的规范定义（自 1970 年 1 月 1 日 00:00:00 UTC 起经过的秒数）。一个看上去就是 floor((date - 1970-01-01) / 1000) 的简单公式值得专门做一个工具，是因为三个时区相关的细节 —— 本地时间还是 UTC、秒还是毫秒、夏令时切换 —— 很容易搞错，而错的结果就是一个偏差若干小时的时间戳。

日期转 Epoch 中「不那么显然」的一点是精度问题。规范的 Unix 时间戳以秒为单位，但大多数现代系统用毫秒（JavaScript 的 Date.now()、Java 的 System.currentTimeMillis()、Python 的 time.time() 返回秒、.time.time_ns() 返回纳秒）。本工具同时输出三种精度，你可以挑与目标系统匹配的那一个。一个常见的 bug 是把不同精度的时间戳混在一起比 —— 拿毫秒戳去跟秒戳比，得到的会是 1970 年的日期而不是 2026 年。本工具的并排显示能在粘贴前帮你发现这类问题。

最终的交接：如果时间戳要进数据库，先确认列类型 —— 大多数数据库有 TIMESTAMP 或 BIGINT 列，精度（秒还是毫秒）必须匹配。如果时间戳要进日志文件或 HTTP 头，规范是秒（RFC 7231 的日期用秒，带亚秒精度的 ISO 8601 也可接受）。如果时间戳是给 cron 作业或定时任务用的，得到时间后可以用 Cron-to-Human 工具以人类可读的形式校验调度表达式。本工具只负责给你数字；目标系统决定怎么用它。

使用方法

输入日期和时间
从日期输入框选择日期，从时间输入框选择时间。默认是浏览器所在时区的「当前时间」。ISO 8601 字符串（`2026-06-16T14:30:00Z`）也可以直接粘贴到文本输入框中。
选择时间戳精度
可选秒（标准 Unix 时间）、毫秒（JavaScript 的 `Date.now()` 以及大多数服务器日志）或纳秒（Go 的 `time.Now().UnixNano()` 以及部分高分辨率遥测）。输出会按所选精度实时刷新。
复制时间戳
点击输出区域的任意一行，即可把对应的时间戳复制到剪贴板。当前时间和解析后的时间并排显示，方便在粘贴前核对转换结果。

常见问题

什么是 Unix 时间戳？

Unix 时间戳是从 1970 年 1 月 1 日 00:00:00 UTC（Unix 纪元）起经过的秒数。它与时区无关 —— 同一个瞬间在所有时区都对应同一个数字。例如 2026-06-16T00:00:00Z 对应 1749936000。

为什么会有秒、毫秒、纳秒之分？

不同系统使用不同精度。Unix C API 用秒；JavaScript 和 Java 用毫秒；Go 和部分高分辨率遥测用纳秒。本工具同时输出三种精度，你可以选择与目标系统匹配的那一个。

时区是如何处理的？

默认使用浏览器所在的本地时区。「UTC」切换开关会把输入切到 UTC。带 `Z` 后缀或带数字时区偏移的 ISO 8601 字符串按该偏移解析；不带后缀的 ISO 8601 字符串按浏览器本地时间解析。

能转换未来或远古的日期吗？

可以 —— Unix 时间戳格式用 32 位有符号整数覆盖 1970 到 2038，用 64 位覆盖 1970 到约 2920 亿年。JavaScript 的 `Date` 对象被限制在 1970 年前后 ±275,000 年范围内；本工具遵循 JavaScript 的这一上限。

闰秒怎么处理？

Unix 时间忽略闰秒 —— 每个 UTC 日恰好是 86,400 秒。2016-12-31T23:59:60（实际的闰秒时刻）的 Unix 时间戳与 2017-01-01T00:00:00 相同。这与 `date +%s` 以及大多数库的返回值一致。

限制说明

JavaScript Date 范围工具内部使用 JavaScript 的 `Date` 对象，可处理的日期范围大约为公元前 271,821-04-20 到公元 275,760-09-13。超出该范围的日期会返回 `NaN` 或 `Invalid Date`。遇到史前或遥远未来的日期，请改用 Python 或 Java 工具。
不做工作日运算本工具只转换日历日期，不识别工作日、节假日或工作时间。如需工作日运算，可在转换后把结果再交给 `business-time` 或 `workalendar` 之类的库处理。
不做历法系统转换输入和输出均使用格里高利历。工具不提供与儒略历、伊斯兰历等其他历法系统之间的转换。1582 年之前的历史日期，由于格里高利历改革，结果可能偏差数日。

平台说明

macOS: macOS Terminal 中的等价命令：`date -j -f '%Y-%m-%d %H:%M:%S' '2026-06-16 14:30:00' +%s`。对于临时性的转换，不值得专门打开终端时，浏览器工具是更合适的选择。
Windows: PowerShell 中 .NET 的等价写法：`[DateTimeOffset]::Parse('2026-06-16T14:30:00Z').ToUnixTimeSeconds()`。需要跨平台一致性时浏览器工具更合适 —— 同样的输入在任何平台上都产生同样的输出。
Linux: GNU coreutils 中的等价命令：`date -d '2026-06-16 14:30:00 UTC' +%s`。对于从聊天、邮件或文档页面粘贴过来的内容，重新输入不现实，浏览器工具是更合适的选择。
CLI: 同样的转换逻辑在每种语言的标准库里都有：Python 的 `calendar.timegm()`、Ruby 的 `Time.now.to_i`、Go 的 `time.Parse().Unix()`。对于不值得专门写脚本的临时性转换，浏览器工具是更合适的选择。
Web: 完全在客户端运行。页面加载后可离线使用。转换依赖 JavaScript 的 `Date` 对象，该对象在夏令时边界附近有已知怪癖 —— 关键场景下请与基准时钟交叉核对结果。