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 8:45 AM, Xueming Shen wrote:
> 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?
>>
>
btw, we do have a ZipEntry.UPPER_DOSTIME_BOUND to help save a timestamp 
into the extra field, if necessary.

-sherman