RFR 6303183: Support NTFS and Unix-style timestamps for entries in Zip files
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.
> Note that we now have both kinds of epochs: 1970 and 1980, for extra
> 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
> 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
> 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.
> I'm yet to run the full regression tests on it, comment/opinions
> are appreciated.
> 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
> 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.
> 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
More information about the core-libs-dev