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

[Xueming Shen]

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