奇怪的org.threeten.bp.DateTimeException抛出?

Weird org.threeten.bp.DateTimeException thrown?

提问人:Ashwin 提问时间:1/9/2016 最后编辑:Meno HochschildAshwin 更新时间:3/8/2016 访问量:701

问:

我的代码工作得很好。今天突然我开始出现这个异常 - 这是我的简单代码: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

为什么突然出现这个问题?

编辑:

这似乎是一个中间问题。它有时会崩溃,有时工作正常。没有关于正在发生的事情的线索。一个

java android 时间 时钟 threetenbp

评论

0赞 sasikumar 1/9/2016
什么是108795?你的约会对象?
0赞 Ashwin 1/9/2016
@sasikumar:其实是1872095944。已更新问题。我不确定这是否是日期。你的意思是以毫秒为单位,对吧?

答:

0赞 user2503849 1/9/2016 #1

api 最近是否有任何更改。我在允许的模式列表中没有看到任何 u 选项。

Symbol  Meaning                     Presentation       Examples

  ------  -------                     ------------      -------

   G       era                         number/text       1; 01; AD; Anno 
Domini

   y       year                        year              2004; 04

   D       day-of-year                 number            189

   M       month-of-year               number/text       7; 07; Jul; July; J

   d       day-of-month                number            10


   Q       quarter-of-year             number/text       3; 03; Q3


   Y       week-based-year             year              1996; 96


   w       week-of-year                number            27

   W       week-of-month               number            27

   e       localized day-of-week       number            2; Tue; Tuesday; T

   E       day-of-week                 number/text       2; Tue; Tuesday; T

   F       week-of-month               number            3


   a       am-pm-of-day                text              PM

   h       clock-hour-of-am-pm (1-12)  number            12

   K       hour-of-am-pm (0-11)        number            0

   k       clock-hour-of-am-pm (1-24)  number            0

   H       hour-of-day (0-23)          number            0

   m       minute-of-hour              number            30


   s       second-of-minute            number            55

   S       fraction-of-second          fraction          978

   A       milli-of-day                number            1234

   n       nano-of-second              number            987654321

   N       nano-of-day                 number            1234000000

   V       time-zone ID                zone-id America/Los_Angeles; Z; -08:30

   z       time-zone name              zone-name  Pacific Standard Time; PST

   X       zone-offset 'Z' for zero    offset-X          Z; -08; -0830; -08:30; -083015; -08:30:15;

   x       zone-offset                 offset-x          +0000; -08; -0830; -08:30; -083015; -08:30:15;

   Z       zone-offset                 offset-Z          +0000; -0800; -08:00;


   p       pad next                    pad modifier      1

   '       escape for text             delimiter


   ''      single quote                literal           '

[       optional section start

 ]       optional section end

{}      reserved for future use

评论

0赞 Ashwin 1/9/2016
我把它改成了'yyyy'。它最初起作用了。但话又说回来,问题又悄悄地出现了,但也有同样的例外。这是一个中间问题。有时它会起作用,有时会抛出例外
0赞 Meno Hochschild 1/31/2016
是的,你有一个过时的 javadoc。实际的人知道 u(作为公历公历年),看看 Oracle
1赞 Meno Hochschild 1/31/2016 #2

这与其说是格式问题(这里只是一个症状),不如说是一个如何创建实例的问题。根本原因很简单,在极少数情况下,似乎会产生完全超出界限的月份。这个问题可能与threeten-bp的问题跟踪器上的这个问题有关。LocalDateTimeLocalDateTime.now()

LocalDate.ofEpochDay(x) 有时会返回错误或非法的结果 而不是为较大的 x 值抛出异常。为 实例, LocalDate.ofEpochDay(9223371671611556645L) 返回一个日期 d.getDayOfMonth() 的负值,而不是抛出 DateTimeException。

请记住,该方法必须在后台进行纪元转换,最后调用 .因此,如果你的时钟从Unix纪元开始产生一个unusal epoch值,以millis为单位,那么这也会影响。而你的格式化程序只是通过有效地调用(实际上是通过字段访问)从你那里获取月中的某一天。有问题的源代码:now()LocalDate.ofEpochDay(...)now()LocalDateTimegetDayOfMonth()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_VALUEepochDay + DAYS_0000_TO_1970Long.MIN_VALUE400 * 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-project 团队能尽快修复它(或者更确切地说是 Oracle!)。无论如何,导致问题的输入可能是错误的,因此您最好捕获异常并使用时钟错误(作为根本原因)的额外消息记录它。

评论

0赞 Meno Hochschild 2/18/2016
与此同时,我发现另一个产生负月度的值是:9223372036854056247L
0赞 JodaStephen 9/5/2016
已在向后移植中修复 - github.com/ThreeTen/threetenbp/issues/39