I am trying to store dates as latest modification timestamp in a ZIP -file. It seems that ZIP format support only dates after 1980-01-01 as a last modification time (at least via Java API java.util.zip.ZipEntry )
Is this correct? Is the earliest supported modification timestamp really 1980-01-01 00:00:00? I tried to find some references to verify this but I couldn't find any.
Zip entry timestamps are recorded only to two 2 second precision. This reflects the accuracy of DOS timestamps in use when PKZIP was created. That number recorded in the Zip will be the timestamp truncated, not the nearest 2 seconds.
When you archive and restore a file, it will no longer have a timestamp precisely matching the original. This is above and beyond he similar problem with Java using 1 millisecond precision and Microsoft Windows using 100 nanosecond increments. PKZIP format derives from MS DOS days and hence uses only 16 bits for time and 16 bits for date. There is defined an extended time stamp in the revised PKZIP format, but Java does not use it.
Inside zip files, dates and times are stored in local time in 16 bits, not UTC as is conventional, using an ancient MS DOS format. Bit 0 is the least signifiant bit. The format is little-endian. There was not room in 16 bit to accurately represent time even to the second, so the seconds field contains the seconds divided by two, giving accuracy only to the even second.
This means the apparent time of files inside a zip will suddenly differ by an hour compared with their uncompressed counterparts every time you have a daylight saving change. It also means that the a zip utility will extract a different UTC time from a Zip member date depending on which timezone the calculation was done. This is ridiculous. PKZIP format needs a modern UTC-based timestamp to avoid these anomalies.
To make matters worse, Standard tools like WinZip or PKZIP will always round the time up to the next even second when they restore, thereby possibly making the file one second to two seconds younger. The JDK (i.e. javaToDosTime in ZipEntry rounds the time down, thereby making the file one to two seconds older.
The format does not support dates prior to 1980-01-01 0:00 UTC. Avoid file dates 1980-01-01 or earlier (local or UTC time).
Wait! It gets even worse. Phil Katz, when he documented the Zip format, did not bother to specify whether the local time used in the archive should be daylight or standard time.
And to cap it off… Info-ZIP, JSE and TrueZIP apply the DST schedule (days where DST began and ended in any given year) for any date when converting times between system time and DOS date/time. This is as it should be. Vista’s Explorer, 7-Zip and WinZip apply only the DST savings, but do not apply the schedule. So they use the current DST savings for any date when converting times between system time and DOS date/time. This is just sloppy.
http://mindprod.com/jgloss/zip.html
tar files are so much better.