Guide
时间戳转换示例：秒、毫秒和日期时间该怎么对应
时间戳转换看起来是一个很小的工具，但它经常出现在接口调试、日志排查、数据库核对和前后端联调里。真正耗时间的不是“转一下”，而是先判断当前值到底是什么格式、该按哪个时区理解，以及要不要反向生成新的时间戳。
先判断这是秒还是毫秒
开发里最常见的错误不是转换函数本身，而是把 10 位秒级时间戳当成 13 位毫秒级时间戳，或者反过来。看到结果离当前日期差几十年时，通常第一件事就是检查位数。
在 JsonDock 的时间戳工具里，先确认输入长度，再看本地时间和 UTC 输出是否合理，能大幅减少“为什么时间对不上”的排查时间。
什么时候要看 UTC，什么时候看本地时间
如果你在排查接口返回、数据库字段或服务器日志，优先看 UTC 往往更稳，因为它能减少时区环境差异带来的误判。
但如果问题来自用户界面、运营配置或业务展示，则通常要同时看本地时间，确认用户看到的日期是否符合预期。
常见的双向转换场景
前后端联调时，经常会先把时间戳转成日期，确认接口返回是否正确；改完参数后，又把新的日期反向生成时间戳用于请求测试。
另一个高频场景是把日志中的时间戳转换成人类可读时间，再和其他系统记录做比对，快速定位哪一个环节产生了延迟或偏差。
常见问题
为什么同一个时间戳在不同地方看起来不一样？
通常是因为展示时区不同。先用 UTC 对齐，再决定要不要换成本地时间来对照业务场景。
什么时候应该怀疑是秒和毫秒弄反了？
当转换结果明显早几十年或晚几十年时，优先检查位数。10 位通常是秒，13 位通常是毫秒。