介绍
这个时间戳转换器适合在浏览器里快速检查 Unix 时间。你可以查看每秒更新的当前时间、时间戳秒值和毫秒值，把已有时间戳转换为本地时间和 UTC 可读日期，也可以把指定的日期时间重新转回 Unix 秒值或毫秒值，用于接口联调、日志排查、数据库检查或定时任务验证。
使用方法
先查看实时面板，确认当前时刻以及对应的 epoch 秒和毫秒。然后在“时间戳转日期”区域输入数值，并选择输入单位是秒还是毫秒，工具会立即显示本地时间、UTC、ISO 8601、星期和相对当前时间。在“日期转时间戳”区域选择本地日期时间后，工具会生成 Unix 秒值和毫秒值。这里的日期输入会按你当前设备时区解释，所以排查时区问题时要特别注意。
功能亮点
- •展示当前时间、epoch 秒和 epoch 毫秒，并且每秒自动刷新
- •支持时间戳转本地时间、UTC、ISO 8601、星期和相对时间
- •支持本地日期时间反向转换为 Unix 秒值和毫秒值
- •适合接口调试、日志排查、JWT 时间声明检查和数据库字段核对
- •所有转换都在浏览器本地完成，不上传服务器
秒和毫秒为什么经常弄混
Unix 时间戳最常见的两种单位是秒和毫秒。很多 API、JWT 声明和后端载荷使用秒，而 JavaScript Date.now() 和不少前端埋点、浏览器日志使用毫秒。如果结果看起来早了很多年或晚了很多年，最常见的原因就是单位选错了。
常见使用场景
时间戳转换经常出现在应用日志阅读、过期时间检查、定时任务验证、埋点事件排查、前后端时钟比对，以及数据库字段类型确认中。它也适合快速判断某个系统到底存的是 epoch 秒、epoch 毫秒，还是已经格式化好的 ISO 时间字符串。
本地时间和 UTC 要一起看
当团队成员、服务器和用户分布在不同时区时，UTC 是最稳定的共同参考。与此同时，本地时间又很重要，因为它更接近用户设备实际看到的时间。把两者放在一起看，可以减少时区偏移、夏令时和本地配置带来的误判。
排查结果不对时先检查什么
如果结果看起来不合理，建议按顺序检查四件事：输入是秒还是毫秒、源系统是否默认 UTC、本地输入是否本该按另一个时区解释、设备时钟本身是否准确。大多数时间戳问题都能在这几步里找到原因。
该选择哪种输入方式
根据数据来源选择更合适的转换路径。
| 输入类型 | 适合场景 | 注意事项 |
|---|---|---|
| epoch 秒 | JWT 声明、很多 API、Unix 命令输出 | 如果日期明显过早，先确认来源是不是其实用了毫秒 |
| epoch 毫秒 | JavaScript Date、浏览器日志、前端事件载荷 | 现代时间通常会表现为 13 位左右 |
| 本地日期时间 | 排查排程、人工核对、数据库录入检查 | 输入会按当前设备时区解释 |
结果字段说明
不同输出格式适合回答不同问题。
| 输出 | 帮助确认什么 | 典型用途 |
|---|---|---|
| 本地时间 | 当前设备看到的时间 | 用户反馈、地区化问题排查 |
| UTC / ISO 8601 | 跨系统共享的统一参考 | 服务端对照、日志分析、团队协作排查 |
| 相对当前时间 | 距离现在有多远 | 过期判断、任务新鲜度、定时检查 |
常见问题
Unix 时间戳应该用秒还是毫秒？
取决于来源系统。很多 API 和 JWT 声明使用秒，而 JavaScript Date 值通常使用毫秒。
为什么转换后的日期差了几百年甚至几千年？
通常是单位选错了。把秒当成毫秒会得到过早的日期，把毫秒当成秒会得到过晚的日期。
日期转时间戳时用的是 UTC 吗？
不是。这里的本地日期时间输入会先按你当前设备时区解释，再转换成 Unix 时间。
为什么要同时展示 UTC 和本地时间？
UTC 适合跨系统统一比对，本地时间则更接近用户或设备实际看到的结果，两者一起看更不容易误判。
这些时间戳数据会上传到服务器吗？
不会。这个转换器完全在浏览器本地运行，输入和结果都留在你的设备上。