[Jazzlib-developers] ZipEntry.setTime() Bug in Jazzlib 0.0.7 ?

[Rang, C. <Chr...@ge...>]

The ZipEntry.setTime() method is implemented as follows:

  public void setTime(long time)
  {
    Calendar cal = getCalendar();
    synchronized (cal)
      {
	cal.setTime(new Date(time*1000L));
	dostime = (cal.get(Calendar.YEAR) - 1980 & 0x7f) << 25
	  | (cal.get(Calendar.MONTH) + 1) << 21
	  | (cal.get(Calendar.DAY_OF_MONTH)) << 16
	  | (cal.get(Calendar.HOUR_OF_DAY)) << 11
	  | (cal.get(Calendar.MINUTE)) << 5
	  | (cal.get(Calendar.SECOND)) >> 1;
      }
    dostime = (int) (dostime / 1000L);
    this.known |= KNOWN_TIME;
  }

Questions:
-> Why is the 'time' parameter multiplied by 1000 for the Date constructor?
According to the original java.util.zip documentation, the parameter is
already in milliseconds, as required by the Date() ctor.
-> Why is the resulting dostime divided by 1000 again at the end?

I did some tests and loaded the resulting ZIP with WinZIP, and the WinZIP
test resulted in:

Teste ...
Bei Datei "xxx.txt" ist das Verzeichnisdatum zentral falsch. Stattdessen
wird das aktuelle Systemdatum verwendet.
Bei Datei "xxx.txt" ist das Verzeichnisdatum lokal falsch. Stattdessen wird
das aktuelle Systemdatum verwendet.
Teste: xxx.txt                 OK
Es wurde mindestens ein Warnung --Fehler in xxx.zip entdeckt.

Sorry - it's a german ZIP version. The error messages mean roughly
translated that the timestamp (central) and the timestamp (local) is wrong,
and that winzip uses the current system time instead.

When I removed the '*1000' in the Date ctor call and the
dosttime=dostime/1000, all worked perfectly - WinZip did no longer issue
warnings and displayed the actual date of the file that was zipped.