java10位时间戳转换不对：从现象到排查的完整思路

先确认拿到的是秒还是毫秒

10位数字通常代表秒级时间戳，而Java里System.currentTimeMillis()返回的是毫秒，长度是13位。把10位值直接塞进按毫秒解析的逻辑，结果会落在1970年附近。

拿输入10做对照：按秒解释得到1970-01-01T00:00:10.000Z，UTC显示1970-01-01 00:00:10，对应毫秒值10000。如果某段代码把这个10当成毫秒，输出时间几乎贴着纪元起点，看起来就像“转换错了”。

排查动作只有一步：数位数。10位按秒处理，13位按毫秒处理。位数对不上时，先怀疑单位，再怀疑代码。

用几个小数值验证解析方向

与其盯着一串真实业务时间反复猜，不如用几个短小的值观察输出规律。输入9得到1970-01-01T00:00:09.000Z，输入11得到1970-01-01T00:00:11.000Z，输入670得到1970-01-01T00:11:10.000Z，输入3610得到1970-01-01T01:00:10.000Z。

这些结果说明：秒级时间戳每增加1，UTC时间就前进1秒；670换算后是11分10秒，3610换算后是1小时0分10秒。数字与时间的对应关系是线性的，没有隐藏偏移。

需要即时对照时，可以打开时间戳转换逐条输入，观察unix、毫秒、ISO与UTC四个字段是否彼此一致。四个字段互相能对上，说明解析方向没问题，差异多半出在后续的格式化环节。

时区差几小时，往往不是转换错误

同一秒级时间戳，在UTC下和在东八区下显示的小时数不同，这是时区偏移，不是数值算错。上面10的UTC结果是1970-01-01 00:00:10，如果展示层按本地时区渲染，钟面读数就会变化。

排查时把两件事分开：先看转换得到的UTC值是否与预期一致，再看展示层有没有叠加时区。日志里记录的时间、数据库存的时间、页面显示的时间，三者若使用了不同的时区设置，对比时就会互相打架。

做法很朴素——统一用UTC比对一次。UTC对得上，问题就在展示层；UTC也对不上，再回头查单位和符号。

负数与边界值容易被忽略

秒级时间戳可以是负数，表示1970年之前的时间。输入-3590得到1969-12-31T23:00:10.000Z，输入-650得到1969-12-31T23:49:10.000Z。如果代码里用了无符号类型，或者转换前做了取绝对值，负值就会被悄悄改掉。

另一类边界是位数临界：10位与13位之间只差三位，肉眼扫日志时容易看漏。建议在解析入口加一条位数校验，位数不符直接报错，而不是静默按某一单位处理。

顺带一提，19位时间戳属于另一种精度表达，和10位不是同一量级，混用时也会出现明显偏差，可参考19位时间戳转换了解它与秒级、毫秒级的对应关系。

把排查固化成三步

第一步，数位数，确认按秒还是按毫秒解析。第二步，用9、10、11这类小值跑一遍，确认输出随时间线性前进。第三步，拿转换结果里的UTC字段与预期时间比对，排除时区干扰。

三步都通过，仍有偏差，就去检查格式化模板里的占位符是否把秒当成了毫秒，或者是否在多处重复做了单位换算。换算做两次，结果自然对不上。

遇到java10位时间戳转换不对，先别改工具，按这三步走一遍，多数情况能在几分钟内定位到具体环节。

相关文章

• jq13位时间戳转换成日期：参数结果核对

  说明参数13按Unix秒转换后的UTC日期，并区分数值13与13位毫秒时间戳。

• jq12位时间戳转换成日期：12 对应哪一刻？

  参数 12 按 Unix 时间戳换算，对应 1970-01-01 00:00:12（UTC），毫秒数为 12000。本文说明结果含义、换算步骤与相邻参数对照。

• jdk8将时间戳转换成instant：8秒的转换结果

  在JDK8中把时间戳8转换为Instant，结果是1970-01-01T00:00:08Z，对应UTC时间00:00:08，毫秒值8000。

• java时间戳转换日期格式14位：先分清秒与毫秒

  从14位时间戳的位数困惑讲起，用实例说明秒与毫秒的差别，并给出Java格式化日期与排查错误的做法。

• java时间戳转换成时间6：从参数6看懂秒级换算

  以参数6为例，讲清Java时间戳换算成时间的思路：秒与毫秒的区别、UTC与本地时区、边界值与常见报错排查。

常见问题