我的问题是，当我们想要存储从地球诞生到地球结束的日期（预计在100000000000000000000-12-31 23:59:00.0000 +1）时，应如何处理日期。
我相信一些科学家有像这样的日期库。由于Joda-Time也使用了很长的内部存储空间，因此它超出了范围。从头开始制作压延机可能很困难，因为我们必须处理所有特殊情况，例如从朱利安换到格里高利历和闰年/秒......
答案 0 :(得分：6)
JSR-310 - Java 8中的新日期/时间API - 已经处理过了。来自Instant docs：
为了实用，瞬间存储了一些约束。可测量的时间线限制为可以长时间保持的秒数。这大于当前估计的宇宙年龄。瞬间存储到纳秒分辨率。
如果你不能等待Java 8出来，那就有一个backport to Java 7。）
但是，JSR-310 可能无法以您希望的方式处理闰秒。基本上它通过坚持任何提供的时钟执行拖尾来尝试（完全合理地）从系统中移除闰秒。 （因此闰秒没有在数据模型中表示。）你需要小心这一点。当然，在遥远的未来，闰秒计算是不可能的，而且几乎肯定是无足轻重的：）
编辑：如下面的答案中所述，上面的引用实际上是一个规范错误，而Instant将“仅”支持高达十亿的年份值。
答案 1 :(得分：4)
没有这样的图书馆可以支持100000000000000000000这样的年份，甚至没有JSR-310。
Jon Skeet正确阅读了java.time.Instant的规范（声称支持长时间可以保持的任意秒数）但忘记了也阅读API元素MAX和MIN的详细信息明显受制于10亿或更少的绝对年份数。所以我们在JSR-310中只有一个规范错误。任何试图获得更大年份数的尝试都将以RuntimeException结束。顺便说一句，JSR-310团队已经意识到规范错误并将修复它，请参阅Oracle-Bug-Log。
这些希望考虑日历规则，如闰年甚至闰秒。好吧，Peter Lawrey做了很好的评论。我想添加以下内容来考虑：
闰秒仅在我的库Time4J中受支持，而不在JSR-310中受支持。但是这个功能对你的实际问题没有任何意义，因为闰秒的预测不能超过ca.提前六个月！所以这个计算很傻。此外，对于许多人来说，令人惊讶的是：即使格里高利历中的闰年规则在未来大约3000-4000年的范围内也不会稳定，因为格里高利历只是对真实太阳年的不完美近似。
所以我的建议，只是忘记你的问题的任何日历库，并使用双原语。这很好。