java - 抛出奇怪的 org.threeten.bp.DateTimeException 异常？

我的代码工作得很好。今天突然我开始收到这个异常 - org.threeten.bp.DateTimeException: Field DayOfMonth cannot be printed as the value 1872095944 max width is 2这是我的简单代码:

LocalDateTime date = LocalDateTime.now();
    DateTimeFormatter formatter = DateTimeFormatter.ofPattern("dd - MM - uuuu");
    String sDate = date.format(formatter);//EXCEPTION THROWN HERE

为什么会突然出现这个问题？
编辑
这似乎是一个中间问题。它有时会崩溃，而在其他时候运行良好。没有关于正在发生的事情的线索。一种

最佳答案

这不是一个格式问题(这里只是一个症状)，而是一个如何创建 LocalDateTime 实例的问题。根本原因很简单，LocalDateTime.now() 似乎在某些极少数情况下产生了完全超出范围的月份日期。这个问题可能与threeten-bp的问题跟踪器上的这个issue有关。

请记住，方法 now() 必须在后台进行纪元转换，最后调用 LocalDate.ofEpochDay(...) 。因此，如果您的时钟自 Unix 纪元以来产生了以毫秒为单位的异常纪元值，那么这也会影响 now() 。并且您的格式化程序只是通过有效调用 LocalDateTime (实际上是通过 getDayOfMonth() 中的字段访问)从您的 TemporalAccessor 中获取日期。有问题的源代码:

281     public static LocalDate ofEpochDay(long epochDay) {
282         long zeroDay = epochDay + DAYS_0000_TO_1970;
283         // find the march-based year
284         zeroDay -= 60;  // adjust to 0000-03-01 so leap day is at end of four year cycle
285         long adjust = 0;
286         if (zeroDay < 0) {
287             // adjust negative years to positive for calculation
288             long adjustCycles = (zeroDay + 1) / DAYS_PER_CYCLE - 1;
289             adjust = adjustCycles * 400;
290             zeroDay += -adjustCycles * DAYS_PER_CYCLE;
291         }
292         long yearEst = (400 * zeroDay + 591) / DAYS_PER_CYCLE;
293         long doyEst = zeroDay - (365 * yearEst + yearEst / 4 - yearEst / 100 + yearEst / 400);
294         if (doyEst < 0) {
295             // fix estimate
296             yearEst--;
297             doyEst = zeroDay - (365 * yearEst + yearEst / 4 - yearEst / 100 + yearEst / 400);
298         }
299         yearEst += adjust;  // reset any negative year
300         int marchDoy0 = (int) doyEst;
301

302         // convert march-based values back to january-based
303         int marchMonth0 = (marchDoy0 * 5 + 2) / 153;
304         int month = (marchMonth0 + 2) % 12 + 1;
305         int dom = marchDoy0 - (marchMonth0 * 306 + 5) / 10 + 1;
306         yearEst += marchMonth0 / 10;
307

308         // check year now we are certain it is correct
309         int year = YEAR.checkValidIntValue(yearEst);
310         return new LocalDate(year, month, dom);
311     }

最有趣和可疑的是 仅验证年份，而不验证月份或月份 的事实。事实上，看看这个奇怪的结果，它包含由减号 (???) 分隔的四个部分:
LocalDate d = LocalDate.ofEpochDay(9223371671611556645L); System.out.println(d); // -999999999-02-0-30 System.out.println(d.getDayOfMonth()); // -30

显然，对于一些可能由您的时钟不幸产生的奇特纪元日期，库代码已损坏。 我也在 Java-8 中测试了相同的代码，结果同样错误。

更新:

到目前为止显示的 LocalDate.ofEpochDay(long) 的原始代码肯定是坏的，也是因为没有检查数字/算术溢出。例如: Long.MAX_VALUE 之类的输入会导致表达式 epochDay + DAYS_0000_TO_1970 溢出并将符号更改为负数。类似地，当使用表达式 Long.MIN_VALUE 时，输入 400 * zeroDay 最终会溢出。而且我担心这不是显示代码的唯一问题。为了比较: gregorian 算法的正确实现更像是在 my own time library 中。

旁注:

在我的库 Time4J 的帮助下，我分析了上面给定的测试输入也将产生远远超出三十基点定义的一年(范围是 -999999999 到 +999999999):
PlainDate date = PlainDate.of(9223371671611556645L, EpochDays.UNIX); // java.lang.IllegalArgumentException: Year out of range: 25252733927766555

我不太确定你能做些什么来解决这个问题。

首先肯定是记录您的时钟产生的所有输入，将它们与观察到的 30-bp 的错误行为联系起来，并进行一些研究，为什么您的时钟有时会发疯。

关于threeten-bp(和Java-8!)中的错误，您只能希望threeten-bp-project 团队能够尽快修复它(或者更确切地说是Oracle!)。无论如何，导致问题的输入可能是错误的，因此您最好捕获异常并使用时钟错误的额外消息(作为根本原因)记录它。
关于java - 抛出奇怪的 org.threeten.bp.DateTimeException 异常？，我们在Stack Overflow上找到一个类似的问题：https://stackoverflow.com/questions/34691990/