RFR JDK-8130914: java/util/zip/TestExtraTime.java fails with "java.lang.RuntimeException: setTime should make getLastModifiedTime return the specified instant: 3078282244456 got: 3078282244455"
xueming.shen at oracle.com
Fri Jul 17 15:45:37 UTC 2015
On 7/17/15 1:04 AM, Peter Levart wrote:
> Hi Sherman,
> On 07/15/2015 09:10 PM, Xueming Shen wrote:
>> 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
> And-ing the result with a 32 bit mask (2^32 - 1) does make sure that
> high 32 bits are not touched by year encoding. As I understand, this
> starts to be a problem with year 2044 and beyond when (year - 1980) <<
> 25 becomes a negative number. Expanding it to long sets the high 32
> bits too. If we treat the lower 32 bits as unsigned, we accommodate
> for years up to and including 2107. At 2108, the overflow happens and
> decoding the year back gives 1980 instead of 2108. So I wonder:
> - will there be a DOS compatible ZIP format after 2108 ?
> - will there be Java after 2108 ?
Yes, dos timestamp has a 2107 ceiling, given it's 32-bit nature, like
the unix time has a 2038 ceiling if
the long stays as 32-bit.
> - depending on the above answers, should there be a DOSTIME_AFTER_2107
> in addition to DOSTIME_BEFORE_1980 to which the date is clamped?
If ZIP is still being used on 2107, "we" have a problem.
> Regards, Peter
>> In which the change is to utilize a high 32-bit of the time value to
>> < 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
More information about the core-libs-dev