Only zip recording timestamps up to two 2 second accuracy. This reflects the accuracy of the DOS timestamps when PKZIP was created. This number recorded in Zip will be a timestamp, not the next 2 seconds.
When you back up and restore a file, it will no longer have a time stamp that exactly matches the original. This above and above a similar problem with Java using 1 millisecond precision and Microsoft Windows using 100 nanosecond increments. The PKZIP format comes from MS DOS days and therefore uses only 16 bits for time and 16 bits for date. An extended timestamp is defined in the revised PKZIP, but Java does not use it.
Inside zip files, dates and times are stored in local time at 16 bits, not UTC, as usual, using the ancient MS DOS format. Bit 0 is the least significant bit. The format is a direct byte order. There was no place in 16 bits for an accurate representation of time even to the second, so the seconds field contains seconds divided by two, giving accuracy only to even the second.
This means that the viewing time of files inside the zip will suddenly differ hourly compared to their uncompressed counterparts each time you have daylight saving time. This also means that the zip utility will extract a different UTC time from the date of registration of Zip, depending on the time zone, the calculation is completed. This is ridiculous. The PKZIP format is a modern UTC-based timestamp to avoid these anomalies.
Even worse, standard tools like WinZip or PKZIP will always have time until the next even second when they are restored, making the file one second to two seconds younger. JDK (i.e. javaToDosTime in ZipEntry rounds the time down, thereby making the file one for two seconds.
The format does not support dates until 1980-01-01 0:00 UTC. Avoid file date 1980-01-01 or earlier (local or UTC time).
Wait! It is getting worse. Phil Katz, when he documented the Zip format, did not need to indicate the local time used in the archive should be daytime or standard.
And to remove it ... Info-ZIP, JSE and TrueZIP applies the DST schedule (days where DST started and ended in any given year) to any date when converting times between system time and DOS date / time. This is as it should be. Vistas Explorer, 7-Zip and WinZip only apply DST savings, but do not apply the schedule. Therefore, they use the current time saving on DST for any date when the conversion time between system time and DOS date / time. It is only clumsy.