上周调试一个 IoT 设备的上报日志，日志里时间戳是 1718956800000，文档写的是秒级，可我一算日期对不上——差了整整 1000 倍。后来用 时间戳转换 一测，发现其实是毫秒级。这种混用场景在开发里太常见了，每次手动除以 1000 再查表，至少浪费 5 分钟。这个工具帮我把验证时间压缩到 10 秒以内，而且不用开计算器。
打开工具后，最快出结果的路径是什么？
这个工具的首页只有两个输入框：左边是时间戳，右边是日期。你不需要点任何切换按钮，直接往左边输入数字，右边立刻显示对应的 UTC 日期和时间。
关键点在于输入框右侧有个下拉菜单，默认是“秒”，但你得先确认你手里的时间戳是秒、毫秒还是微秒。比如刚才那个 1718956800000，如果选“秒”，结果会是 1970 年 1 月 21 日，明显不对；切换到“毫秒”，立刻显示 2024-06-21 00:00:00，这才是正确的。
不用点任何“转换”按钮，输入即出结果。如果要从日期转回时间戳，在右边输入日期，左边会同步显示秒、毫秒、微秒三个值。整个操作就是“输入—看结果”，没有多余步骤。
三个真实场景分别怎么用？
场景一：后端日志里的时间戳到底是多少秒？
你从日志里复制出一个时间戳，比如 1625097600000。直接贴进工具，下拉选“毫秒”，看到日期是 2021-07-01 00:00:00。如果你怀疑它是秒级，下拉选“秒”，显示 2021-07-01 00:00:00 吗？不会，显示的是 1970 年 1 月 19 日。所以只要看到日期明显不对，立刻知道它是毫秒。这个判断过程只需 2 秒。
场景二：前端展示需要把日期转成多时区的时间戳
假设你有一个活动时间是 2026-06-21 15:00:00（北京时间），前端需要传给后端一个 UTC 时间戳。在工具右边输入这个日期，注意时区选“Asia/Shanghai”，左边会显示对应的时间戳，比如 1718967600（秒）。如果你需要毫秒，工具直接给出 1718967600000，不用自己乘 1000。
场景三：微秒级精度的时间戳验证
某些高性能日志会记录微秒，比如 1718967600000000。在工具里下拉选“微秒”，直接看到日期。这个场景在普通计算器里很难手动验算，因为除以 1000000 容易出错，但工具一次搞定。
什么时候别用它？
这个工具不处理非标准纪元的时间戳。比如有些系统用 1970-01-01 00:00:00 作为起点，但偏移量加了 30 年（像某些金融系统），这个工具无法识别，你需要先减去偏移量再输入。
另外，它不支持闰秒。如果你处理的是天文观测或 GPS 数据，里面包含闰秒调整，工具给出的结果会差 1 秒。这种情况下，建议用专门的闰秒处理库。
还有一点：它没有批量转换功能。如果你有 100 个时间戳要转，只能一个一个来。这时候可以考虑搭配 Excel 的公式，或者用 Python 脚本。
搭配哪些工具更顺手？
调试日志时，我经常先查一下日志里的手机号归属地，确认设备来自哪个运营商，这能帮我判断日志格式是不是按运营商规范来的。你可以用站内的 手机归属地查询 来快速判断。比如看到一个 138 开头的号码，归属地是中国移动，日志里时间戳格式通常是毫秒级，这是行业惯例。
另一个常用搭配是 房贷计算器，虽然和本文无关，但当你需要算项目上线时间节点时，用房贷计算器的等额本息明细来模拟时间分配，反而比甘特图直观。
总之，时间戳转换的核心价值是消除秒/毫秒/微秒的歧义，让你在 10 秒内确认手里的数字到底对应哪一天。下次遇到日志里一串数字，别急着开计算器，先贴进这个工具看看。