间隔1天的Date对比差1秒？getDateAfter测试返回86399秒问题排查

两次获取当前时间的执行间隔导致毫秒级误差：
你在waitIfNeeded执行完成后，先调用LocalDateTime.now()获取today，再调用timeService.getDateAfter(1)。假设getDateAfter方法内部是基于调用时的当前时间计算加1天的结果，哪怕两次调用只间隔1毫秒，最终计算出来的两个时间的差就是86400秒 - 1毫秒。而ChronoUnit.SECONDS.between计算时间差时会截断小数部分，直接返回整数秒数，所以结果就是86399。

你写的waitIfNeeded本身逻辑就不严谨：它只在当前毫秒数大于500的时候等待到下一秒，要是当前毫秒数是499，你没有等待逻辑，后续两行代码执行只要耗时超过1毫秒，就必然出现上述误差。

• 时区/夏令时问题：你断言一天固定为86400秒本身就不成立。如果系统默认时区有夏令时规则，在夏令时切换的日期，一天可能是23小时（82800秒）或者25小时（90000秒），这种场景下测试必然失败。
• 闰秒/特殊时间场景：虽然Java 8+的时间API默认不处理闰秒，但如果你的部署环境启用了闰秒调整，极端情况下会出现一天有86399秒或者86401秒的情况，也会导致断言失败。闰年的日期计算Java本身的时间API已经处理完善，不会导致秒数差的问题，但如果你的getDateAfter方法自己实现了日期加逻辑没有处理闰年，会出现日期计算错误。
• 类型转换风险：你把getDateAfter的返回值先转Instant再转系统时区的LocalDateTime，如果getDateAfter返回的时间本身是基于其他时区（比如UTC）计算的，转换后会出现小时级的误差，进一步导致秒数差不符合预期。
• 测试设计缺陷：依赖系统当前时间的单元测试本身就是不稳定的，正确的实现方案是给TimeService注入Clock依赖，测试时使用固定时间的Clock实例，完全规避执行时间差的影响，不需要额外的等待逻辑。

内容的提问来源于stack exchange，提问作者Kovo