Code change looks OK to me, but perhaps there should be an explicit long
conversion somewhere around the getYear() part ('d.getYear() - 1980 << 25L') of
the expressions to deal properly with even larger values?
Are there added tests missing from the updated TestExtraTime? I guess this is
an intermittent issue, but it looks odd to update the test without adding some
explicit test that provoke this issue.
/Claes
Xueming Shen <xueming.s...@oracle.com> skrev: (15 juli 2015 21:10:39 CEST)
>Hi,
>
>Please help review the change for JDK-8130914.
>
>issue: https://bugs.openjdk.java.net/browse/JDK-8130914
>webrev: http://cr.openjdk.java.net/~sherman/8130914/
>
>This is a "regression" triggered by
>https://bugs.openjdk.java.net/browse/JDK-8130914
>http://cr.openjdk.java.net/~redestad/jdk9/8073497/webrev.6/
>
>In which the change is to utilize a high 32-bit of the time value to
>store
>< 2000 ms time piece. It appears the offending timestamp (year 2067...)
>triggers the 32-bit "overflow" when converting java time to a 32-bit
>dos
>time.
>
>Thanks,
>-Sherman
