Unix 时间戳转换工具
在 Unix 时间戳（纪元秒/毫秒）与可读日期时间之间相互转换。支持多个时区显示、一键填入当前时间，以及相对时间显示，专为开发者设计。
Unix 时间戳基础知识
Unix 时间戳是以1970年1月1日 00:00:00 UTC（Unix 纪元）为起点、以经过的秒数来表示日期时间的一种方式。下表列出了一些具有代表性的时间戳数值及其对应的日期。
| 时间戳（秒） | UTC 日期时间 | 备注 |
|---|---|---|
| 0 | 1970-01-01T00:00:00Z | Unix 纪元（所有时间戳的起点） |
| 1000000000 | 2001-09-09T01:46:40Z | 时间戳达到10亿秒的瞬间（Unix Billennium） |
| 1234567890 | 2009-02-13T23:31:30Z | 因数字恰好按1至9顺序排列而被人津津乐道的数值 |
| 2147483647 | 2038-01-19T03:14:07Z | 2038年问题：32位有符号整数所能表示的最大值（1秒后即发生溢出） |
Unix 时间戳转换工具是什么
这是一款可以在 Unix 时间戳（纪元秒/纪元毫秒）与人类可读的日期时间之间双向转换的在线工具。粘贴一串数字，即可立即看到它对应的 ISO 8601（UTC）时间、相对时间（例如"3小时前"）以及 UTC、东京、纽约、洛杉矶、伦敦、巴黎共6个时区下的具体时刻；反过来，选定日期时间和时区后也能马上算出对应的纪元秒和纪元毫秒。所有计算均在浏览器本地完成，不会把任何数据发送到服务器，可放心用于排查含有真实用户信息的日志。
工具内置的位数自动判断功能，会依据绝对值是否达到万亿级（即1万亿，10^12）来推测输入的究竟是秒还是毫秒，省去了每次手动切换单位的麻烦。日期转时间戳时还会正确处理夏令时切换期间的偏移量计算，并对2月30日这类实际不存在的日期给出明确的错误提示，避免得到看似正常实则错误的结果。顺带一提，以32位有符号整数存储的系统会在2038年1月19日 03:14:07 UTC（即纪元秒达到2,147,483,647，这是32位有符号整数所能表示的最大秒数）之后发生溢出，这就是广为人知的"2038年问题"；现代64位系统基本不受影响，但排查旧系统或嵌入式设备的数据时，了解这个背景会很有帮助。
Unix 时间戳转换工具的使用方法
- 选择转换方向 页面分为"时间戳→日期"和"日期→时间戳"两张卡片，先确定自己要做哪一种转换。
- 粘贴或输入时间戳 在"时间戳→日期"卡片中输入数字，单位可保持"自动判断"，也可手动指定为秒或毫秒。
- 查看多时区结果 转换结果会显示 ISO 8601（UTC）、相对时间，以及 UTC、东京、纽约、洛杉矶、伦敦、巴黎同一时刻的本地时间对照表。
- 或者选择日期时间与时区 切换到"日期→时间戳"卡片，选好日期时间控件的值和所在时区，即可得到对应的纪元秒和纪元毫秒。
- 需要当前时间时点击"填入当前时间" 两张卡片都提供该按钮，点击后会立即取用浏览器本机时间填入输入框，省去手动查表的步骤。
用好本工具的小技巧
- 10位数通常代表"秒"，13位数通常代表"毫秒"。选择"自动判断"即可根据位数自动推测单位。
- 可以直接粘贴服务器日志或API响应中的时间戳，一次性确认它在多个时区下对应的时间。
- 在"日期→时间戳"转换中，请务必明确选择输入日期时间所对应的时区。
- ISO 8601（UTC）格式几乎可以被所有编程语言和数据库直接解析，在检索日志或设计API时非常实用。
- 点击"填入当前时间"按钮，即可立即从浏览器的 Date.now() 获取当前时间并填入输入框。
这些场景可以用得上
排查服务器与应用日志
很多日志系统只记录纪元秒或纪元毫秒，把可疑记录的时间戳粘贴进来，一眼就能看出它对应本地时间的哪个时段，加快定位问题的速度。
API 开发与联调
调试 REST/GraphQL 接口时，经常需要确认请求或响应里的时间字段是否正确，用本工具可以快速校验单位（秒还是毫秒）以及时区换算是否符合预期。
核对数据库时间戳字段
数据库中的 created_at、updated_at 等字段有时以整数形式存储，导出几条记录后直接转换，能快速确认写入时间是否符合业务逻辑。
跨时区团队协作排期
和分布在不同国家的同事约定会议或发布时间时，把候选时间戳转换成各自时区的本地时间，能避免"时差算错"导致的会议迟到或误会。
生成测试数据与示例代码
编写单元测试或接口文档示例时，常常需要一个具体、可复现的时间戳，用"填入当前时间"或手动输入即可快速生成，方便直接粘贴进代码。
术语解释
- Unix 时间戳（纪元秒）
- 以1970年1月1日 00:00:00 UTC 为起点，经过的秒数。因为是不依赖时区的单一数值，被广泛用作计算机之间交换时间的标准格式。
- Unix 纪元
- 1970年1月1日 00:00:00 UTC 这一基准时刻，所有 Unix 时间戳都以它为零点开始计数。
- UTC（协调世界时）
- 不受任何地区夏令时或时区偏移影响的国际标准时间基准，是计算机系统内部记录和交换时间时最常使用的时间标准。
- 纪元毫秒
- 以毫秒（千分之一秒）为单位表示的 Unix 时间戳，数值是对应纪元秒的1000倍，JavaScript 的 Date.now() 等 API 默认返回的就是这种单位。
- ISO 8601
- 国际标准化组织制定的日期时间表示格式，形如"2026-09-20T12:00:00Z"，几乎所有编程语言和数据库都能直接解析，非常适合用于日志和API交换。
- 2038年问题
- 以32位有符号整数存储 Unix 时间戳的系统，会在2038年1月19日 03:14:07 UTC（即达到该类型能表示的最大值 2,147,483,647 秒）之后1秒发生数值溢出，导致日期错误地倒退回1901年前后。
- 夏令时（DST）
- 部分国家和地区在夏季将时钟拨快一小时以延长日照利用时间的制度，在计算跨越切换日期的时间差或做日期转时间戳运算时需要额外留意。
- 相对时间
- 以"3小时前""2天后"等相对于当前时刻的说法来表达时间距离的方式，比直接显示绝对日期时间更符合人类的直觉阅读习惯。
常见问题
闲话 ― 为什么计算机用"秒数"来计时
人类习惯用"2026年7月12日 17点8分"这样年月日与时刻组合的方式表示日期时间，但对计算机来说这种格式并不友好：闰年、时区、夏令时等复杂规则每次都需要考虑，即便只是计算两个日期之间的间隔也需要繁琐的处理。于是人们想出了只用一个数值——距某个基准时刻经过的秒数——来表示时间的方法，这正是 Unix 时间戳。
将时间表示为单一整数值的最大优点，在于日期之间的比较与加减运算都可归结为简单的四则运算。要计算"两个事件相隔多少秒"，只需将两个时间戳相减即可，完全不必顾虑闰年或每月天数不同的问题。正因为这种简洁性，该格式不仅被类 Unix 系统采用，也被 Windows、数据库以及众多编程语言的内部表示所采纳，成为事实上的全球标准。
另一方面，这种"不依赖时区的单一数值"的设计，也意味着时区转换只有在人类需要读取它时才变得必要。同一个时间戳，在东京看可能是深夜，在纽约看则可能是前一天下午——显示时所选的时区不同，看到的日期时间会截然不同。在排查日志或调试API对接时遇到的"时间对不上"这类令人困惑的故障，很多正是源于对这种时区转换的疏忽。