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

[Peter Levart]

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 ?
- depending on the above answers, should there be a DOSTIME_AFTER_2107 
in addition to DOSTIME_BEFORE_1980 to which the date is clamped?

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