这不是一个格式问题(这里只是一个症状),而是一个实例如何的问题LocalDateTime
被建造。根本原因很简单LocalDateTime.now()
似乎产生了月份中的某一天完全超出范围在一些罕见的情况下。这个问题可能与此有关issue关于 Threeten-bp 的问题跟踪器。
LocalDate.ofEpochDay(x) 有时会返回错误或非法结果
而不是针对较大的 x 值引发异常。为了
实例,LocalDate.ofEpochDay(9223371671611556645L) 返回一个日期
d.getDayOfMonth() 的值为负值,而不是抛出
日期时间异常。
请记住该方法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中测试了相同的代码,得到了相同的错误结果。
Update:
原来的代码为LocalDate.ofEpochDay(long)
到目前为止显示的肯定是损坏的,也是因为没有检查数字/算术溢出。例如:像这样的输入Long.MAX_VALUE
导致表达式epochDay + DAYS_0000_TO_1970
溢出并将符号更改为负数。类似的,输入Long.MIN_VALUE
使用表达式时最终会溢出400 * zeroDay
。我担心这不是所显示代码的唯一问题。为了比较:格里高利算法的正确实现更像是我自己的时间图书馆.
边注:
在我的图书馆的帮助下Time4J我分析过,上面给定的测试输入也会产生远远超出 Threeten-bp 中定义的一年(范围是 -999999999 到 +999999999):
PlainDate date = PlainDate.of(9223371671611556645L, EpochDays.UNIX);
// java.lang.IllegalArgumentException: Year out of range: 25252733927766555
我不太确定你能做什么来解决这个问题。
第一件事肯定是记录时钟产生的所有输入,将它们与观察到的 Threeten-bp 的错误行为联系起来,并研究为什么你的时钟有时会发疯。
关于 Threeten-bp(和 Java-8!)中的错误,您可以只希望 Threeten-bp 项目团队很快修复它(或者更确切地说 Oracle!)。无论如何,导致问题的输入可能是错误的,因此您最好捕获异常并使用时钟错误的额外消息(作为根本原因)记录它。