先保留原值，再判断秒还是毫秒
看到日志里的长整数时，先复制原值到排查记录，不要直接在原日志里改写。常见 Unix 时间戳使用秒或毫秒；单位判断错三位，转换结果就可能偏到完全不合理的年代。
例如接口日志同时出现 1787412600 和 1787412600123。前者接近 10 位，通常按秒理解；后者接近 13 位，通常按毫秒理解。位数是很有用的初筛，却不是业务证明：有些系统会记录微秒、纳秒、单调计时值或自定义纪元，所以仍要查字段说明和产生日志的代码。
当前Unix 时间戳转换工具（timestamp）只接受整数文本。它把绝对值小于 100000000000 的输入当作秒并乘以 1000，其余按毫秒交给浏览器日期对象；非整数、超出 JavaScript 安全整数范围或无法形成日期的值不会得到正常结果。这个规则适合快速核对常见秒级与毫秒级值，不等于识别所有日志格式。
同一个时刻要连同时区标签一起读
转换后的日期必须和时区名称放在一起记录。页面会把同一时刻分别显示为台北、纽约、伦敦和东京时间；四行看起来不同，代表的仍是同一个瞬间，而不是四次事件。
假设告警写着 09:10，客服工单写着 21:10，如果一个来自纽约、一个来自台北，两者可能恰好指向同一时刻。只抄“9 点 10 分”而漏掉时区，会把显示差异误判成延迟。排查笔记可保留三项：原始整数、确认的单位、带时区的转换结果。
纽约和伦敦会受夏令时规则影响，浏览器使用可用的 Intl.DateTimeFormat 时区资料来显示日期。页面不会告诉你日志生产者当时用了哪个时区，也不会读取服务器设置。若日志字段旁已有 Z、+08:00 或明确区域名，应以来源格式为准，不能为了让时间“看起来对”而随意换区。
用相邻事件验证，不要只相信一个日期
一个结果落在今年并不代表单位判断正确。把登录请求、鉴权结果、数据库写入和告警通知等相邻事件按原始值比较，再看间隔是否符合系统流程。
例如用户在页面点击提交后约两秒看到成功提示，那么请求与响应相差约 2000 毫秒或 2 秒都合理；如果转换后相差 33 分钟，先检查两个字段是否用了不同单位，而不是立即判断数据库阻塞。保留原值可以让你重新计算，不必从格式化文字反推数字。
需要比较两份少量日志摘要时，可以先删掉令牌、Cookie、邮箱和客户资料，再把相同字段整理到文字差异比对逐行查看。若原始片段是 JSON，可用JSON 格式化工具看清层级，但格式化不会解释字段语义，也不会自动统一时间单位。
日期反转为时间戳时先确认浏览器本地时区
右侧日期输入框是 datetime-local，没有自带时区。页面会把你输入的年月日时分按当前浏览器本地时区解释，再输出秒和毫秒两种值。因此，给远端服务器制作测试值前，要先写明电脑当前时区。
比如身处上海的开发者输入 2026-08-23 09:00，浏览器会按本机设置解释；同事在纽约输入相同的墙上时间，得到的时间戳不会相同。若测试规范要求 UTC，应先在具备明确 UTC 输入能力的系统里生成，或按项目文档完成换算，不要假设 datetime-local 就是 UTC。
ToolboxHub 只转换一个粘贴值或一个本地日期输入，不会打开、批量修改或保存日志文件，也不会验证服务器时钟是否同步。转换后仍要把结果放回请求 ID、事件顺序和系统时区中核对。
转换后的最小检查清单
完成一次换算后，至少核对单位、时区和事件顺序。任何一项说不清，都应把结果标记为“待确认”，不要写成已经定位根因。
- 原始数字是否完整，复制时有没有丢掉负号或末尾三位？
- 字段文档写的是秒、毫秒，还是其他精度？
- 显示结果是否带有台北、纽约、伦敦或东京等明确标签？
- 与前后事件的间隔是否符合用户操作和系统流程？
- 日期反转时，浏览器本地时区是否就是测试要求的时区？
排查记录最好同时保存原值与解释，例如“1787412600123，按毫秒，纽约时间……”。这样其他人可以独立复核，而不是只能相信一段没有单位的日期文字。
常见问题
10 位一定是秒、13 位一定是毫秒吗？
常见现代日志大多如此，但不是绝对规则。工具按数值阈值自动判断，字段文档、生产代码和相邻事件才是最终核对依据。
为什么纽约和台北显示的日期不同？
它们是同一瞬间在不同时区的本地显示。记录结果时必须保留时区标签，否则只比较时钟数字会产生误判。
工具可以直接上传整份日志并批量转换吗？
不能。当前页面处理单个整数或本地日期输入，不读取日志文件，也不会替你寻找字段、删除敏感信息或改写原记录。
datetime-local 输入的是 UTC 吗？
不是固定 UTC。浏览器会按电脑当前本地时区解释该输入；生成测试时间戳前应先确认系统时区和项目要求。
转换出合理日期就能证明服务器时间正确吗？
不能。转换只说明这个数字能映射为日期。服务器时钟、日志写入延迟、队列顺序和字段单位仍需要其他证据验证。