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.shen@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