A zip-file created with cygwin's "zip" command contains an additional timestamp
entry for the modification-date. However, this timestamp is in seconds since the
UNIX epoch. However, ZipEntry interprets this a dostime, so when getTime() is
invoked, a wrong number is returned.
See the discussion thread on:
A sample source illustrating it is given below, and the output is shown below
when tested on two zip-files - one created with cygwin's zip, and one with WinZip:
=== GCJ ===
# ./zipdates fromzip.zip
ZipDates.java date: 313906034000 Thu Dec 13 03:07:14 GMT-01:00 1979
# ./zipdates fromwinzip.zip
ZipDates.java date: 1126270914231 Fri Sep 09 12:01:54 GMT-01:00 2005
The test-application is compiled using GCJ, and is confirmed by Ranjit Mathew to
be present in a "recent" version.
I'll attach the two zip-files...
=== ZipDates ===
* Feel free to use this source.
* Martin Egholm - 2005.
public class ZipDates
public static void main(String args) throws IOException
if (args.length < 1)
System.out.println("Missing filename argument...");
} // if
ZipFile zf = new ZipFile(args);
Enumeration entries = zf.entries();
ZipEntry entry = (ZipEntry) entries.nextElement();
System.out.println(entry.getName() + "\tdate: " + entry.getTime()
+ "\t" + new java.util.Date(entry.getTime()));
} // while
} // else
} // main
} // ZipDates
Created attachment 9715 [details]
The zip-file created with Cygwin's "zip" reproducing the bug
Created attachment 9716 [details]
Produced with "WinZip" with same content as other zip-file, but correct timestamp returned from ZipEntry
This bug still exist in current CVS (future 0.96). Seems to be fixed if we don't parse the UT block.
The main issue seems to be that the UT block stores the modification time in seconds as an integer, and this is then passed as milliseconds to the calendar class. Multiplying it by 1000 beforehand gives a more sensible result, but we still seem to be out by 1 hour.
java ZipDates with_cygwin.zip
ZipDates.java date: 1126601898000 Tue Sep 13 09:58:18 BST 2005
ZipDates.java date: 1126598298000 Tue Sep 13 08:58:18 British Summer Time 2005
Not sure if this is a bug in our zip implementation or in our date handling.
Subject: Bug 23854
Module name: classpath
Changes by: Andrew John Hughes <gnu_andrew> 07/10/07 18:48:46
. : ChangeLog
java/util/zip : ZipEntry.java
2007-10-07 Andrew John Hughes <firstname.lastname@example.org>
(parseExtra()): Pass time to setTime in milliseconds
rather than seconds by multiplying by 1000.
unzip -l gives the same result as Classpath:
unzip -l with_cygwin.zip
Length Date Time Name
-------- ---- ---- ----
806 09-13-05 08:58 ZipDates.java
806 1 file
Not sure what the JDK is doing, maybe this is a bug there? Can someone with a different timezone test the ZipDates code on OpenJDK and tell me the result? Or can the original submitter please confirm this is the correct time. Thanks.
Created attachment 14318 [details]
Created attachment 14319 [details]
Fix for seconds to milliseconds
I'm assuming this is now fine.