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
<[email protected] <mailto:[email protected]>> 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.
