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