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]

On 7/17/15 1:04 AM, Peter Levart wrote:
> Hi Sherman,
>
> On 07/15/2015 09:10 PM, Xueming Shen wrote:
>> 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/
>
> 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.

-Sherman

> Regards, Peter
>
>>
>> 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
>