日历是否满足闰秒的需求？

1. GregorianCalendar不满足闰秒的需求（Oracle的源代码视图显示了这一点 - 那里总是给出1分钟= 60秒的明确假设）。此外：Oracle现在已经正式拒绝了闰秒支持 - 请参阅Bug-ID 4272347。
2. 在Java中，没有标准的第三方库支持闰秒 - 甚至没有joda时间。只有像这样的专业软件才能做到这一点。
3. 请注意，许多库确实在谈论闰秒，尽管不支持，例如java.util.Date（参见Dorofeevs的答案）。此外，JSR 310 也讲了很多，但不支持此功能。官方的JSR 310支持UTC-SLS，它不计算闰秒，只描述围绕闰秒事件的涂抹橡胶秒。事实上，JSR 310 是否支持 UNIX 时间或 UTC-SLS 非常令人困惑（请参阅下一点）。由于闰秒信息（github/threeten/issues/197）已从 JSR 310 代码库中删除，因此在 JSR 310 的范围内实现真正的 UTC 闰秒是绝对不可能的。在最好的情况下，你可能会期望一个即将到来的外部模块（Threeten-Extra）作为JSR 310的补充，它充其量只能提供基本的支持（它更像是UNIX时间和TAI时间尺度之间的转换，而不是更多，在我看来，它使用了一个根本错误的域模型）。
4. System.currentTimeMillis()正式与操作系统计时器有关。由于我所知道的所有操作系统，包括微软，Linux和苹果都只是基于UNIX规范，这个java系统计时器不计算闰秒，只有自1970-01-01T00：00：00.000Z以来的正常毫秒
5. 由于所有这些事实，我决定建立自己的日期和时间java库，名为Time4J，它完全支持闰秒，并且可以作为v1.0与LGPLv2.1许可证。一篇 dzone 文章演示了 v4.2 版中的这种支持。

java.util.Date API 说

"...尽管 Date 类旨在反映协调世界时 （UTC），但它可能无法完全反映协调世界时 ，具体取决于 Java 虚拟机的主机环境。...大多数计算机时钟不够精确，无法反映闰秒的区别。

维基说

“由于地球的自转速度因气候和地质事件而异，因此UTC闰秒的间距不规则且不可预测。每个UTC闰秒的插入通常由国际地球自转和参考系统服务（IERS）提前六个月决定。

也就是说，没有一个班级可以知道未来的IERS决定。