zip - ZIP文件格式支持的最早的时​​间戳值是什么？

Question

我正在尝试将日期作为最新的修改时间戳存储在ZIP文件中。似乎ZIP格式支持仅在1980-01-01之后的日期作为最后一次修改时间(至少通过Java API java.util.zip.ZipEntry)

这样对吗？最早支持的修改时间戳确实是1980-01-01 00:00:00吗？我试图找到一些引用来验证这一点，但找不到任何引用。

Answer 1

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文件好得多。