Unix 时间戳生成器，免费

工作原理

1. 日期转时间戳：使用选择器输入日期和时间，然后点击「生成」获取秒和毫秒形式的 Unix 时间戳。
2. 时间戳转日期：粘贴 Unix 时间戳（秒或毫秒），将其转换回可读的日期和时间。
3. 获取当前时间戳：点击「现在」即时获取当下的 Unix 时间戳。

为什么使用 Unix 时间戳生成器？

Unix 时间戳是计算机系统中时间的通用语言 · 一个整数，表示自 1970 年 1 月 1 日（UTC）以来经过的秒数。它们驱动数据库、API、日志、身份验证令牌和事件调度。手动在时间戳和可读日期之间转换需要时区计算，极易出错。此工具正确处理双向转换，节省时间并避免时区 bug。

功能特性

• 双向转换：日期/时间 → Unix 时间戳，以及 Unix 时间戳 → 日期/时间。
• 秒与毫秒：同时支持秒级（10 位）和毫秒级（13 位）Unix 时间。
• 时区处理：同时显示本地时区和 UTC 时间，便于明确比较。
• 当前时间按钮：立即获取当下的时间戳。
• 相对显示：显示距离多久之前或多久之后（如「3 天前」）。

常见问题

什么是 Unix 时间戳？

Unix 时间戳是自 Unix 纪元（UTC 1970 年 1 月 1 日午夜）以来经过的秒数。它是与时区无关的时刻表示，因此成为数据库和 API 中存储和比较时间的首选格式。

为什么 JavaScript 使用毫秒？

JavaScript 中的 Date.now() 和 new Date().getTime() 返回自纪元以来的毫秒数（13 位数字），而 Unix 工具和大多数数据库使用秒（10 位）。检查您的时间戳是 10 位还是 13 位，即可知道属于哪种格式。

如何将时间戳转换为本地时间？

粘贴时间戳后，工具会自动将其转换为您浏览器的本地时区。显示同时展示本地时间和 UTC，便于放心处理跨时区场景。

Unix时间从何而来

Unix时间由Ken Thompson和Dennis Ritchie在Unix First Edition(1971年11月)中定义。最初内核以1971-01-01为起点以60分之一秒为单位在32位字段中计数,2年9个月后溢出。在Unix Sixth Edition(1975)中,计数被改为自1970-01-01 00:00:00 UTC以来的秒数,这是每个类Unix系统今天仍在使用的纪元。这个选择是任意的,工程师们需要一个接近他们工作时代的整数日期。POSIX.1(1988)将该定义编纂为官方标准,而POSIX.1-2017(IEEE Std 1003.1-2017),即当前版本,仍将time_t定义为自纪元以来的秒数,但要注意POSIX时间假装闰秒不存在。ISO 8601(1988,当前2019)标准化了可读格式2026-05-13T14:30:00Z,而RFC 3339(2002年7月)将其缩小为明确的互联网日期时间配置文件。JavaScript的Date.now()返回自纪元以来的毫秒,因为该规范于1995年编写,当时已经对亚秒精度有需求;大多数数据库和Unix实用工具仍使用整秒。

2038年问题(以及它现在为什么重要)

32位有符号的time_t最多可表示2,147,483,647秒,这将在2038年1月19日星期二UTC 03:14:07到达。一秒钟后,计数器回绕到−2,147,483,648,大多数软件将其解释为1901年12月13日。这与Y2K是同一类bug,但由整数宽度引起,而不是日期格式。解决方案是使用64位time_t(将回绕推到大约公元2920亿年)。大多数64位Linux系统已经默认使用64位time_t;Linux 5.6(2020年3月)使64位time_t在32位架构上也可用。剩余的风险存在于嵌入式系统、旧的二进制文件格式和32位网络协议中。网络时间协议(NTP)已在2036年回绕,因为它使用自1900年以来的无符号32位计数,NTPv4添加了一个时代号来扩展它。如果你交付处理日期的软件,在2038年之前审查你的栈,特别是类型为INT(11)的SQL列或带有long时间字段的旧C代码。

你将遇到的时间戳格式

• Unix秒(10位)。 1747143000。经典的POSIX time_t。被PostgreSQL EXTRACT(epoch FROM ...)、MySQL UNIX_TIMESTAMP()、Redis TTL、JWT iat/exp声明(根据RFC 7519)、git log和大多数Unix实用工具使用。2286年11月后将是11位。
• Unix毫秒(13位)。 1747143000000。JavaScript的Date.now()、Java的System.currentTimeMillis()、Kafka、Elasticsearch和大多数现代日志管道。秒计数乘以1000。
• Unix微秒(16位)和纳秒(19位)。 1747143000000000。被Python的time.time_ns()、Go的time.Now().UnixNano()、etcd MVCC修订和毫秒分辨率太粗糙的高频交易系统使用。
• ISO 8601。 2026-05-13T14:30:00.000Z或2026-05-13T14:30:00+02:00。作为字符串可排序,时区明确,几乎所有现代API都接受。Z后缀意为「Zulu时间」,是UTC的北约指示符。
• RFC 3339。ISO 8601的更严格的配置文件,被JSON Schema、OpenAPI和大多数REST API使用。需要时区指示符并禁止某些ISO 8601功能,如周日期和顺序日期。
• RFC 2822 / RFC 5322。 Tue, 13 May 2026 14:30:00 +0000。电子邮件Date:头格式。因为SMTP无处不在,仍然无处不在。
• Excel序列日期。自1900-01-01以来的小数天数(经典Mac Excel上是1904年)。2026-05-13 14:30大约是46150.6042。Excel臭名昭著地将1900年视为闰年(它不是)以与Lotus 1-2-3兼容。

此工具发挥其作用之处

• JWT调试。令牌有"exp": 1747143000,你需要知道它是否过期。粘贴,查看人类日期。
• 日志取证。一行说timestamp=1747143012345,你需要与另一个工具的挂钟时间相关联。13位,所以是毫秒。
• 数据库查询。你想找到特定日期之后的行。WHERE created_at > 1747143000需要秒值;从工具复制它。
• 测试夹具。在测试中硬编码「昨天」,你现在生成时间戳并粘贴到规范中。
• Cron / 计划作业。验证调度程序将触发的秒值,尤其是跨DST过渡。
• 事件重放。Kafka偏移和Elasticsearch索引经常使用毫秒时间戳;转换为日期以检查特定重放窗口。
• 缓存失效。RFC 2822格式的Expires头或If-Modified-Since,为测试生成正确的wire格式。

让团队花费数小时的错误

• 混淆秒和毫秒。将10位值传递给期望毫秒的函数会返回1970年的日期,偏差为1000倍。10对13位规则是最快的测试,秒的现代值到2286年都是10位,毫秒为13位。
• 存储本地时间。始终存储UTC;在显示时转换为本地。存储"2026-05-13 14:30:00"而不带时区,在服务器、用户或DST跳跃改变本地偏移的那一刻就会失效。
• 忘记DST过渡。凌晨2:30在回退期间发生两次。做start + (24 * 3600)以表示「明天」的天真代码每年会偏差一小时两次。使用真正的日期库(luxon、date-fns-tz、Python zoneinfo)了解IANA tz数据库。
• 假设POSIX时间考虑闰秒。它没有。2016-12-31 23:59:60在现实生活中存在(第27个闰秒)但POSIX time_t从23:59:59跳到00:00:00,完全不知道额外的秒。TAI(国际原子时)确实计算闰秒,POSIX时间相对于UTC偏移零秒。
• 将time_t存储在INT(4)列中。旧的MySQL模式经常使用INT,即4字节/32位有符号/2038年回绕。迁移到BIGINT或TIMESTAMP。托管MySQL提供商的TIMESTAMP类型默认也是4字节,请查看文档。
• 使用正则解析ISO 8601。半实现默默丢弃时区。使用平台解析器:JavaScript中的new Date(s),Python ≥ 3.11中的datetime.fromisoformat(s),Java中的Instant.parse(s)。
• Excel自动转换时间戳。将1747143012345粘贴到Excel而不在前面加'(字面撇号)使Excel将其读取为数字,有时转换为科学记数法。要么先将列格式化为文本,要么用撇号前缀粘贴。

更多常见问题

为什么选择1970-01-01作为纪元?

便利。20世纪70年代早期的Unix版本想要一个不会在合理工作生命周期内溢出的纪元。1970-01-01是一个接近开发时代的整数日期,从那里开始的32位秒计数器舒适地达到2038年。这个选择现在被刻在POSIX.1-2017 §4.16中,是软件中最稳定的跨平台协议之一。日期没有固有意义,没有历史事件,没有天文锚点,只是大家都同意的一个任意锚点。

UTC、GMT和Zulu时间有什么区别?

出于软件目的,它们指代相同的挂钟时间。UTC(协调世界时)是现代标准,由原子钟和BIPM定义。GMT(格林尼治标准时间)是较旧的英国天文标准,在原子计时之前是事实上的世界参考。Zulu时间是UTC的北约/军用指示符,写为ISO 8601中的Z后缀(2026-05-13T14:30:00Z)。UTC和GMT最多可相差0.9秒,因为UTC通过闰秒被引导保持接近UT1(平太阳时),但没有不直接使用UT1的应用程序会注意到。

为什么有时显示1970,而我期望的是其他东西?

两个常见原因。首先,时间戳是毫秒但被传递给期望秒的函数,反之亦然,给出一个偏差1000倍的日期。其次,值是0或NaN,这两者大多数日期库都呈现为1970-01-01T00:00:00Z。检查原始整数宽度:10位是秒,13位是毫秒,16位是微秒,19位是纳秒。

此工具会处理1970年之前日期的负时间戳吗?

是的。new Date(-86400000)返回1969-12-31T00:00:00Z。JavaScript的Date可以表示从−271821-04-20到+275760-09-13的任何时刻,即大约从纪元开始的±100亿天。在该范围之外,API返回Invalid Date。对于历史日期,还要注意儒略-格里高利转换(天主教国家1582年,英国1752年,希腊晚至1923年)其中日历日期跳跃了10到13天;日期库在如何处理这一点上各不相同。

我的时间戳数据会被发送到任何地方吗?

不会。所有转换都在浏览器内的JavaScript中运行。该页面从不POST你输入的任何值。在DevTools中打开网络选项卡并转换一个时间戳,你将看到转换期间零出站请求。对于带有时间戳声明的令牌、内部日志行或任何你不会粘贴到托管服务的内容都是安全的。