FormLab

时间戳与时区

Unix 时间戳 ↔ 人类时间,多时区同屏对比,ISO 8601 / RFC 2822 格式化。

当前 Unix 时间(实时)
—
现在
—
本地时区

Unix 时间戳 → 多时区

人类时间 → Unix 时间戳

批量格式化(一次性查看多种格式)

它能解决什么问题

时间戳是程序世界唯一可靠的"时间"。本工具帮你:

使用技巧

  • 秒 vs 毫秒:现代 API 一般用毫秒(如 JS Date.now()、Java System.currentTimeMillis()),老系统用秒。13 位数字通常毫秒,10 位通常秒。
  • 2038 年问题:Unix 32 位秒时间戳在 2038-01-19 03:14:07 UTC 溢出。Node.js / PostgreSQL 等现代系统已用 64 位。
  • 时区数据库:本工具使用 IANA 时区(如 Asia/Shanghai)。Windows 系统有时区别名(CST),建议升级到 IANA。
  • 夏令时:北美的"夏令时"会让时间在 3 月、11 月跳跃。本工具会自动处理。

FAQ

为什么浏览器显示的时间和服务器不一样?

服务器一般用 UTC(避免时区混乱),展示给用户时再转本地。检查你看到的"时间"是带时区还是不带时区(无时区 = 内部时区)。

用「时间戳与时区」时最容易踩的坑是什么?常见的易错点集中在四处:一是把百分数和小数混着填,比如 20 填成了 0.2;二是漏填选填项后直接按默认值算,得到一个看起来正常但不是你想要的数;三是中途改了其中一个输入却忘了重新计算,页面上还留着上一轮的旧结果;四是把页面上写的「参考值」当成了「准确值」往对外的材料里搬。改完任何一项输入,都重新点一次计算按钮再读结果。
「时间戳与时区」的适用边界在哪里?Unix 时间戳与人类时间互转,多时区同屏对比,ISO 8601 / RFC 2822 格式化,当前时间实时显示。 换句话说,它解决的是「按你给的条件做一次快速估算」这一类问题,不适用于需要查权威数据、核对官方文件,或者要逐条审合同、做专业判断的场景。凡是结果会直接影响到花钱、签约、对外承诺的事情,都应该回到原始资料和官方口径再确认一次,把这里的输出当作中间的一步,而不是终点。
「时间戳与时区」的结果应该怎么看?先看最后给出的那个数值,再回到这一段解释里对照:Unix 时间戳与人类时间互转,多时区同屏对比,ISO 8601 / RFC 2822 格式化,当前时间实时显示。 看的时候把「数值本身」和「数值成立的前提」分开看,前者是你填进去的东西算出来的,后者决定了它在什么情况下才算数。数值变大或变小分别代表什么,页面在这一节里已经写清楚了。
拿到「时间戳与时区」的结果后可以直接照着做吗?把它当成做决定前的一份对照材料,比当成答案更稳妥:Unix 时间戳与人类时间互转,多时区同屏对比,ISO 8601 / RFC 2822 格式化,当前时间实时显示。 这一页给出的是在当前输入下算出来的一个量级,它并不包含你的实际执行成本、突发情况和对方可能的变化。真正落地之前,再把结果和实际条件对一遍,看看哪些假设在现实里不成立。
时间戳与时区需要填写哪些信息?「时间戳与时区」一共用到 1 个输入项:毫秒。这些字段在页面上是按计算顺序排下来的,前面的输入会直接影响后面的结果,所以不要跳过看不懂的那一栏。建议先把每个数字的单位口径对齐再动手填,单位不统一是这类计算里最常见、也最容易被忽略的错误来源。
开始用「时间戳与时区」之前需要先确认什么?建议先确认三件事:一是你要解决的问题,是不是正好落在它的适用范围里,别拿一个相邻的工具硬套;二是手上每个数字的统计口径和时间点是否一致,比如同一年里有的按月、有的按年,直接混用会让结果失真;三是算完之后有没有留出复核的余地,比如把关键输入记下来,方便回看时知道当时用的是哪一组数。
谁适合用「时间戳与时区」,谁不适合?适合的是手上已经有明确数字、需要快速得到一个量级参考的人,比如在做预算草案、给同事对齐口径、或者上课前先估算一遍的人。不适合的是想把结果当精确值直接对外承诺的人,也是不适合连输入项口径都还没定下来就开始算的情况——这种情况下先花几分钟把口径理清,比算完之后再来回改数字省事得多。
「时间戳与时区」怎么用才不容易算错?按页面「使用说明」那一段的顺序来:Unix 时间戳与人类时间互转,多时区同屏对比,ISO 8601 / RFC 2822 格式化,当前时间实时显示。 使用方法的关键在于「顺序」和「口径」两件事:先按顺序把需要的量准备好,再确认每一项的单位和你要解决的问题一致。这两点做到了,基本不会算错;漏掉任何一点,结果都会整体偏掉。

相关工具