RFR 6303183: Support NTFS and Unix-style timestamps for entries in Zip files

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