这不是一个格式问题（这里只是一个症状），而是一个LocalDateTime 的实例是如何创建的问题。根本原因很简单，LocalDateTime.now() 在极少数情况下似乎会产生一个完全超出范围的一个月中的某天。这个问题可能和threeten-bp的issue tracker上的这个issue有关。
LocalDate.ofEpochDay(x) 有时会返回错误或非法的结果
而不是为 x 的大值抛出异常。为了
例如，LocalDate.ofEpochDay(9223371671611556645L) 返回一个日期
d.getDayOfMonth() 为负值，而不是抛出
日期时间异常。
请记住，方法now()必须在后台进行一次epoch转换，最后调用LocalDate.ofEpochDay(...)。因此，如果您的时钟自 Unix 纪元以来产生了一个以毫秒为单位的异常纪元值，那么这也会影响now()。您的格式化程序只是通过有效地调用getDayOfMonth()（实际上是通过TemporalAccessor 中的字段访问）从您的LocalDateTime 中获取日期。有问题的源代码：
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 的帮助下，我分析了上面给定的测试输入也会产生超出三个 10 bp 定义的范围的一年（范围是 -999999999 到 +999999999）：
PlainDate date = PlainDate.of(9223371671611556645L, EpochDays.UNIX);
// java.lang.IllegalArgumentException: Year out of range: 25252733927766555
我不太确定你能做些什么来解决这个问题。
首先肯定是记录您的时钟产生的所有输入，将它们与观察到的 30bp 的错误行为联系起来，并研究为什么您的时钟有时会发疯。
关于threeten-bp（和Java-8！）中的错误，您只能希望threeten-bp-project 团队会尽快修复它（或者更确切地说是Oracle！）。无论如何，导致问题的输入可能是错误的，因此您最好捕获异常并将其与时钟错误的额外消息一起记录（作为根本原因）。