Unix 时间戳转换
粘贴时间戳或日期，得到其余各种写法。
什么是 Unix 时间戳
Unix 时间戳（也叫 epoch 时间或 POSIX 时间）是从 1970 年 1 月 1 日 00:00:00 UTC 起经过的秒数（不计闰秒）。它是计算机存储和交换时间点最常用的方式，因为它只是一个整数，不依赖时区、日历或地区格式。数据库、日志、JWT 令牌、API 和操作系统都在用它，所以开发者总需要在 1700000000 这样的原始数字和人能读懂的日期之间来回转换。
不同系统的精度不同。Unix 和大多数数据库存的是秒（目前 10 位）。JavaScript 的 Date.now() 和 Java 的 System.currentTimeMillis() 返回毫秒（13 位）。一些日志系统和 Go 的 time 包会暴露微秒（16 位）或纳秒（19 位）。本工具根据位数自动识别单位，任何一种粘贴进来都不用手动选格式。
使用方法
顶部的实时时钟每秒更新当前 Unix 时间戳（秒），点「复制」直接取用，点「使用当前」把它填进转换框。在输入框粘贴一个时间戳，表格即时填充：秒、毫秒、ISO 8601（多数 API 使用的标准）、RFC 1123 格式的 UTC 字符串、带时区名称的本地日期时间、「3 天后」「2 小时前」这类相对描述、星期几、一年中的第几天以及 ISO 周数。
反向同样可用。输入 2025-03-01、2025-03-01T14:30:00Z 或 March 1 2025 14:30 这样的日期，会由浏览器的日期引擎解析并转换为 epoch 秒和毫秒。没有明确时区的日期按你的本地时区解释，与 JavaScript 的行为完全一致。
时区、ISO 8601 与常见坑
时间戳本身没有时区，只有它的显示形式才有。同一个 1700000000 在伦敦是 22:13，在上海是次日 06:13。当两个系统的时间正好相差几个小时，几乎总是时区混淆造成的。系统间交换时间请优先使用带明确 Z 或偏移量的 ISO 8601 字符串（2024-11-14T22:13:20Z）或原始 epoch 数字，而不是本地日期串。另一个经典 bug 是把秒和毫秒搞混：看到 55000 年或 1970 年的日期，通常就是单位错了，输入框下方的「识别为」提示会告诉你工具采用了哪个单位。最后别忘了 32 位限制：用有符号 32 位整数存秒的系统会在 2038 年 1 月 19 日溢出。
背景：为什么是 1970 年
Unix 纪元由贝尔实验室的 Unix 开发者在 1970 年代初选定；第一版从 1971 年起以 1/60 秒计数，几个月内就溢出了，于是改为从 1970 年 1 月 1 日起按整秒计数——一个安全地落在不久前的整日期。因为它忽略闰秒，每个 Unix 日恰好是 86,400 秒，算术变得极其简单，这也是该格式从 Unix 扩散到所有数据库、编程语言和网络协议的原因。2038 年问题（有符号 32 位计数器回绕）正是这一早期设计的直接遗产；现代系统用 64 位存储，未来 2920 亿年内都安全。
应用领域
时间戳是 JWT 令牌里的 exp、iat、nbf 声明，是几乎所有数据库的 created_at 列，是大多数日志行的第一个字段，也出现在 HTTP 缓存头、cron 与调度系统、区块链的区块头、文件系统元数据（mtime），以及决定 CDN 能否复用缓存页面的 ETag/Last-Modified 逻辑中。当工单里写着「导出在 1718000000 失败」，这个转换器就是把它变成人类日历上时间的方式；写测试时，把一个固定日期转成 epoch 秒，就得到了一个稳定、与时区无关的断言值。本站的结构化数据以及你构建的任何 JSON API，都应该用 ISO 8601 字符串保证可读、用 epoch 整数做运算。
常见问题
怎么获取当前的 Unix 时间戳？
本页顶部实时显示。代码里：shell 用 date +%s，JavaScript 用 Math.floor(Date.now()/1000)，Python 用 int(time.time())。
时间戳是秒还是毫秒？
10 位是秒，13 位是毫秒。工具按长度自动识别，并告诉你采用了哪个单位。
本地时间用的是哪个时区？
你浏览器的时区，显示在时钟旁边。UTC 和 ISO 8601 两行始终是 UTC，可以安全地粘贴到其他系统。
为什么我的日期差了一天？
不带时间和时区的日期串会按本地零点解析，转成 UTC 后可能跨过日期边界。用明确的时间和时区（如 2025-03-01T00:00:00Z）即可避免歧义。
支持负数时间戳和 1970 年以前的日期吗？
支持。负数从纪元往回数，例如 -86400 是 1969 年 12 月 31 日。