RFR JDK-8130914: java/util/zip/TestExtraTime.java fails with "java.lang.RuntimeException: setTime should make getLastModifiedTime return the specified instant: 3078282244456 got: 3078282244455"

[Roger Riggs]

Hi Sherman,

Sorry for the delay,  that looks fine.
If zip is still around that far in the future, everyone will have the 
same problem.

Roger



On 7/17/2015 12:12 PM, Xueming Shen wrote:
> 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