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

[Martin Buchholz]

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.

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>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/~sherman/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/~sherman/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.
>
>
>