RFR JDK-8161942: java.util.zip.ZipEntry.java not covering UpperLimit range of DOS epoch

[Claes Redestad]

Looks good to me. Good to know we'll be all set for 2038 now! ;-)

/Claes

On 07/22/2016 11:26 PM, Xueming Shen wrote:
> Hi,
>
> Please help review the change for JDK-8161942
>
> issue: https://bugs.openjdk.java.net/browse/JDK-8161942
> webrev: http://cr.openjdk.java.net/~sherman/8161942/webrev
>
>
> The current ZipInputStream/ZipEntry implementation stores the "date-time"
> into the ZIP file/entry's extended timestamp fields in extra data, 
> when the
> date-time is out of the MS-DOS range (1980 - 2107.xxx), by using the
> info-zip's extended timestamp, which by specification is in "unix 32-bit
> timestamp", which unfortunately has the 2038 problem (the seconds 
> overflow
> after 2038-...). So when the date-time set for ZipEntry.setTimeLocal() is
> later than the dos-date-time's upper bound 2107, it also too big for the
> info-zip's extended timestamp.
>
> One approach to solve this problem is simply to update the spec to say
> if the date-time is too big for the MS-DOS date-time range, the 
> behavior is
> undefined, given it will take a while for any zip file to have such a 
> timestamp
> in any real world use scenario :-) But since the other newly added (1.8)
> set|getLastModified|LastAccess|CreationTime methods are also suffering
> the same problem when the date-time set is later than 2038, it appears
> it might be worth putting in an implementation that at least works for
> such timestamp. The proposed change here is to use the MS NTFS time
> format to store such timestamps when the unix-32-bit-timestamp is
> too small to store them.  MS NTFS time format is one of the formats
> supported by our implementation (also supported by zip/unzip command)
> when reading the zip entry, the only disadvantage is it's a little 
> bigger,
> take total 36 bytes for three timestamps. But given the fact that we 
> should
> not see such timestamps for at least another 20 years, I would not be 
> worried
> about the size difference, for now.
>
> Thanks,
> Sherman
>
>
>