RFR 6303183: Support NTFS and Unix-style timestamps for entries in Zip files (original) (raw)

Xueming Shen xueming.shen at oracle.com
Sat May 25 00:03:01 UTC 2013

On 5/24/13 3:53 PM, Martin Buchholz wrote:

Thanks very much for adding this support. Users will be happy.

You could make it clearer in the javadoc that you are storing and returning times in seconds since the epoch, and that the epoch is Jan 1, 1980.

This change actually also "partially" fixeds that ZipEntry dos 1980 epoch bug as well since the ZipEntry.set/getEntry() no longer do the java<->dos conversion. While the time stamp in the loc/cen time field still stores the dos formatted time stamp (therefor still has the 1980 issue), with the additional Info-ZIP's extra time stamp the ZipEntry from those zip file should now have the time stamp of the "normal" 1970 epoch.

-Sherman

Note that we now have both kinds of epochs: 1970 and 1980, for extra confusion. Also, I guess the zip world doesn't have any kind of year 2038 strategy? Probably roll over as we get close to 2038 and pray? Probably include links to both appnotes, the pkware one and info-zip's modified version.

On Fri, May 24, 2013 at 12:22 PM, Xueming Shen <xueming.shen at oracle.com <mailto:xueming.shen at oracle.com>> wrote: I'm trying to address the following two issues 6303183: Support NTFS and Unix-style timestamps for entries in Zip files 7012868: (zipfs) file times of entry in zipfs should always be the same regardless of TimeZone. which mainly is about the "mtime" field in both loc and cen tables are dos format, (it means the default time stamp of a zip entry is 2-second granularity time stamp and timezone sensitive (the time is interpreted as the "local time" of the timezone the system is running on, it does not count the time zone difference) The proposed change here is to (1) add a Info-ZIP timestamp in entry's extra data (like zip/unzip does), which uses typical "unix style" second granularity time stamp and is in UTC/GMT timezone (2) change the ZipEntry.time (renamed to mtime) to be the new unix-style-second granularity/UTC time, instead of the current "dos style-2-second granularity and local-time" time stamp, so the set/getTime() can just do the set/get directly without conversion, however the ZipIn/OutputStream and ZipFile need to handle the conversion when dealing with the ZIP formatted time stamp. (3) the "ZipEntry" from ZipOutputStream/ZipFile now has a better time stamp if the zip file has the Info-ZIP formatted time stamp or the NTFS style time stamp (which has the microsecond granularity) (4) For ZipFileSytem, it now output the NTFS style time stamp on Windows platfrom and Info-ZIP style on non-Windows platform. http://cr.openjdk.java.net/~sherman/6303183/webrev/ <http://cr.openjdk.java.net/%7Esherman/6303183/webrev/> I'm yet to run the full regression tests on it, comment/opinions are appreciated. Thanks, -Sherman PS. There is a more "complete" alternative, in which the creation time and last access time are supported via ZipEntry with the NTFS/Info-ZIP time stamp, but I guess there might be no string request for it for now, so it might be better to stay with the "simple" version for now. http://cr.openjdk.java.net/~sherman/6303183/webrev.full/ <http://cr.openjdk.java.net/%7Esherman/6303183/webrev.full/> This proposal is to add two new fields, atime and ctime into ZipEntry and generate NTFS and Info-ZIP's extended timestamp based on the platform os the jvm is running on.

More information about the core-libs-dev mailing list