01970-01-01 00:00:00 GMT+00:00关于 Unix 时间戳转换器
排查线上问题时经常需要把日志里的那串数字换算成人能读的时间：1664582400 到底是几号几点、报表里的毫秒时间戳为什么比秒时间戳多三位、某个接口返回的时间是不是落后了八小时。时间戳转换工具解决的就是这类「数字与可读时间互转」的高频动作。 时间戳（Unix 时间）定义为「自 1970-01-01T00:00:00Z 起经过的秒数」，它本身是 UTC 的，与时区无关；时区只在把时间戳格式化成人看的字符串时才介入。这一点是理解所有时间问题的起点：把时间戳存库、按用户时区渲染是正确的做法，反过来把「本地墙上时间」当成时间戳存储，跨时区必然出现几小时偏移。 使用要点：先确认手里的数字是秒还是毫秒——十位多为秒，十三位多为毫秒，误判会让结果差上几万天；格式化时显式指定时区，不要依赖运行环境的默认时区，否则同一段代码在开发机与服务器上输出不同；需要机器交换时一律用带 Z 或显式偏移的 ISO 8601 字符串，不要用本地格式。 边界与限制：32 位有符号整数能表示的时间戳在 2038-01-19 溢出，老系统与部分嵌入式数据库仍有这个限制，设计长期存储时应直接使用 64 位；夏令时会让某些时区在切换日的同一本地时间出现两次或缺失，做「每天固定时间执行」的调度必须基于 UTC 而不是本地时间；闰秒在 Unix 时间戳体系里被抹平（每天固定 86400 秒），因此时间戳与真实物理时间存在秒级偏差，做高精度计时应使用单调时钟。 数据与隐私：时间戳本身不含敏感信息，但它经常与用户行为日志、订单时间、访问记录一起出现，单独一个时间戳加上业务上下文就可能定位到个人。本工具在浏览器内完成换算，输入不会被发送到服务器，可以断网使用。
跨系统交换时有几条能省下大量排查时间的实践。数据库层面，PostgreSQL 的 timestamptz 会按会话时区转换，MySQL 的 DATETIME 原样存取而 TIMESTAMP 会转换，选型前必须明确要的是哪一种语义，否则同一行数据在不同连接的时区下会显示成不同值。接口层面，一律返回带 Z 或显式偏移的 ISO 8601 字符串，或在字段名里写明单位（如 created_at_ms），让调用方不必猜。日志层面，服务器统一以 UTC 记录并在展示层换算，能避免多机房日志按时间排序时错位。展示层面则相反：面向用户的时间应当换算到他所在时区，并考虑跨日的表达方式（如「昨天 23:40」比完整日期更易读）。把「存储用 UTC、展示用本地」这条规则写进工程规范，比事后逐处修正便宜得多。
与调度场景结合时还应注意：cron 表达式默认按服务器本地时区解释，容器基础镜像多为 UTC，这就造成「本机测试在早上跑、线上却在半夜跑」。部署到容器时把时区显式写进配置或镜像，而不是依赖默认值。 把时区写进接口文档与数据库注释里，是防止下一位维护者重新踩坑的最低成本做法。
实现原理
时间戳定义为自 1970-01-01T00:00:00Z 起经过的秒数，它本身是 UTC 的、不含时区；时区只在格式化成字符串时才介入。因此十位数字通常是秒、十三位通常是毫秒，二者相差一千倍，误判会让结果差出数万天。存储用时间戳、展示按用户时区渲染，是唯一不会出错的分工。
16645824002022-10-01T00:00:00Z（UTC）＝ 北京时间 2022-10-01 08:00:00使用方法
- 打开时间戳转换工具
- 输入 Unix 时间戳（秒或毫秒）或选择日期时间
- 自动转换为可读日期格式和 ISO 8601 格式
- 查看时区信息和相对时间
- 支持批量转换：每行输入一个时间戳
使用场景
- 读日志时间 — 把日志里的 Unix 时间戳转成本地日期，定位事件发生的具体时刻。
- 排查时区 — 对同一时间戳切换 UTC 与本地时区，确认是否存在时区偏移问题。
- 构造测试值 — 把指定日期转成时间戳，填入接口或数据库做边界条件测试。
- 核对过期 — 把 token 或缓存的过期时间戳转成日期，判断是否已经失效。
- 毫秒辨别 — 判断一串数字是秒还是毫秒，避免相差一千倍的换算错误。
常见问题
怎么区分秒和毫秒？
工具按数字位数自动判断：10 位通常是秒，13 位通常是毫秒。你也可以手动指定单位，避免误判导致时间偏差。
Unix 时间戳的起点是什么？
是从 1970 年 1 月 1 日 00:00:00 UTC 起经过的时间，与时区无关；显示时才按你选的时区做偏移。
支持负数时间戳吗？
支持。负值表示 1970 年之前的时间，可用于换算更早的历史日期。
2038 年问题会影响它吗？
2038 问题源于 32 位有符号整数溢出。本工具用更大范围的数值处理，不受 32 位限制，能正常转换 2038 年以后的时间。
换算结果会受我电脑时区影响吗？
默认按你选择的时区显示。若选本地时区，结果会随系统设置变化；建议排查问题时显式选择 UTC 以避免歧义。
为什么接口返回的时间和我本地差 8 小时？
多半是时区问题：接口按 UTC 存储，而你用本地时区（中国为 UTC+8）查看。排查时先确认该值单位（秒还是毫秒），再统一转到 UTC 比对；若字段名以 Z 结尾或含 Utc 说明源就是 UTC。把同一时间戳在该工具里同时切到 UTC 与本地并排显示，若差值恰为整小时数，即可判定是时区差异而非数据损坏，再去修正存储或显示时的时区约定。
同一时刻为什么按秒和按毫秒显示的时间不同？
单位弄错了。秒一般是 10 位、毫秒一般是 13 位；把秒当毫秒用会得到 1970 年附近的极早时间，把毫秒当秒用则会约偏移千年。多数编程语言时间函数返回毫秒（如 JS 的 Date.now()、一般数据库 datetime(3)），而不少日志与命令（如 date +%s）返回秒。拿不准就先看位数，或取一段已知时间戳对照校准，再决定按哪个单位转换。
时间戳是 10 位还是 13 位？
10 位是秒级，13 位是毫秒级（JavaScript Date.now() 的默认输出）。把毫秒当秒解析会得到公元 5 万年，反之会得到 1970 年。工具通常能自动识别位数，但 11–12 位的边界值需要手动指定单位。