Las marcas de tiempo de entrada de la cremallera se registran solo con una precisión de 2 segundos. Este refleja la precisión de las marcas de tiempo de DOS en uso cuando se creó PKZIP . Ese número registrado en el código postal será la marca de tiempo truncada, , no los 2 segundos más cercanos.
Al archivar y restaurar un archivo, ya no tendrá una marca de tiempo que coincida exactamente con el original. Este está por encima y más allá del problema similar con Java usando 1 milisegundo precisión y Microsoft Windows usando incrementos de 100 nanosegundos. El formato PKZIP se deriva de los días de MS DOS y , por lo tanto, utiliza solo 16 bits para el tiempo y 16 bits para la fecha. Se ha definido una marca de tiempo extendido en el formato PKZIP revisado , pero Java no lo usa .
interior con cremallera archivos, fechas y horas se almacenan en horario local de 16 bits, no UTC como es convencional, usando un antiguo formato MS DOS. El bit 0 es el bit menos significativo. El formato es little-endian. No había espacio en 16 bit para representar con precisión el tiempo ni siquiera en el segundo, por lo que el campo segundos contiene los segundos divididos por dos, dando precisión solo al segundos.
Esto significa que el tiempo aparente de archivos dentro de una postal va repente diferir en una hora en comparación con sus homólogos sin comprimir cada vez tiene un cambio horario de verano. Es también significa que la utilidad a zip extraerá una hora UTC diferente de una fecha de miembro Zip dependiendo de la zona horaria que se realizó el cálculo. Esto es ridículo. El formato PKZIP necesita una marca de tiempo moderna basada en UTC para evitar estas anomalías.
Para empeorar las cosas, las herramientas estándar como WinZip o PKZIP será siempre ronda el tiempo hasta la próxima segunda incluso cuando se restauran, con lo que posiblemente haciendo que el archivo de un segundo a dos segundos más joven. El JDK (es decir javaToDosTime en ZipEntry redondea el tiempo abajo, con lo que el archivo de uno a dos segundos más.
El formato no es compatible con las fechas antes 1980-01-01 0:00 GMT. Evitar fechas de archivo 1980-01-01 o anterior (hora local o UTC).
¡Espera! Se pone aún peor. Phil Katz, cuando documentó el formato Zip, no se molestó en especificar si la hora local utilizada en el archivo debería ser luz natural o hora estándar.
Y para colmo de males ... Info-ZIP, JSE y TrueZIP aplicar el programa de horario de verano (días donde el horario de verano de inicio y final de cualquier dado años) para cualquier fecha al convertir veces entre la hora del sistema y DOS fecha /hora. Esto es como debería ser. Vista's Explorer, 7-Zip y WinZip aplican solo los ahorros del horario de verano, pero no aplican el horario. Por lo tanto, utilizan el ahorro de DST actual para cualquier fecha cuando convierte tiempos entre la hora del sistema y la fecha/hora de DOS. Esto es solo descuidado.