Why does the timestamp of a file increase by up to 2 seconds when I put it in a ZIP archive, then extract it?


We saw some time ago that the timestamp of a file increases by up to 2 seconds when you copy it to a USB thumb drive. The underlying reason is that USB thumb drives tend to be formatted with the FAT file system, and the FAT file system records timestamps in local time to only two-second resolution.

The same logic applies to ZIP archives. The ZIP archive format records file times in MS-DOS format, so it too is subject to the two-second resolution limitation.

And the reason the time increases to the nearest two-second interval rather than rounding is so that files do not go backward in time. This is useful when you freshen a ZIP archive: If the file time went backward, then the freshen operation would always report that there were files that needed to be updated.

From the point of view of time stamps, the ZIP archive acts like a tiny FAT-formatted USB thumb drive.

Bonus chatter: If you want to copy files whose timestamps are newer, but take into account MS-DOS timestamp rounding, you can use the robocopy command with the /FFT command line options.

Comments (38)
  1. skSdnW says:

    The .zip specification specifies optional fields for NTFS (64-bit MAC times) and Unix (32-bit MA times) but I guess Explorer does not support them.

  2. Engywuck says:

    @skSdnW: ZIP gained this ability quite a bit after it was first introduced (sometime between 1993 and 2001, according to the published APPNOTEs), so not supporting it is quite understandable. Also it would provoke suppport calls "sometimes my ZIP extracts to the correct time of the original file, sometimes not. WTF?"

  3. viila says:

    @engywuck Might've been understandable in early 2000s, but, c'mon, it's been 15+ years!

  4. morlamweb says:

    @viila: if the goal of Explorer is to create Zip files with maximum compatibility, then it's continued use of MS-DOS timestamps is understandable.

  5. frenchguy says:

    @morlamweb: These fields can be safely used anyway, if an extractor can simply ignore any extra field it doesn't support. The MS-DOS timestamp fields must still be present anyway. And I expect the ZIP extractor used by Explorer to be able to read these fields.

  6. DWalker says:

    @Raymond: "And the reason the time increases to the nearest two-second interval rather than rounding is so that files do not go backward in time."

    Wouldn't it be useful to allow files to go backward in time?  That way, Windows 7 could have been shipped in 1995.

    And all of the problems that need a time machine to solve, would be solvable!

  7. Timothy Byrd (ETAP) says:

    "if an extractor can simply ignore any extra field it doesn't support"

    After reading this blog, you can still make the assumption that all extractors were written to do this?

  8. morlamweb says:

    @Timothy Byrd: my thoughts exactly.  How can one be so sure that all ZIP file extractors would safely ignore those fields that they do not support?  If max compatibility is the goal of Explorer (an assumption, I know, but a safe one to make), then creating ZIP files without the new timestamps is the safe way to go.

  9. David Totzke says:

    Feature Request From: @frenchguy

    Explorer should support the new(ish) timestamp fields for .ZIP files when available.

    To: @frenchguy

    Request Received.  Your feature has been assigned an initial weight of -100 points.  The link below will provide you with some insight into the point ranking system.

    blogs.msdn.com/.../57985.aspx

    Thank you.

  10. Nick says:

    Good news: this post serves as a reminder that for most people in the US and Canada, time changes Sunday.

  11. Darran Rowe says:

    Although due to rounding errors, the post came to late for those whose time zones changed last week.

  12. Cesar says:

    @Timothy Byrd: speaking of ZIP file extractors...

    One project I inherited had a ZIP file extractor DLL. I tracked its source, and found out it was a very old open-source ZIP extractor component written in Delphi. We had a bit of a problem generating ZIP files it would accept; Info-ZIP (the "zip" command on most Unix systems, though we used a Windows build of it) worked reliably, so I standardized on it.

    So yeah, problematic ZIP extractors do exist (though that one probably didn't choke on Unix timestamps in ZIP files).

  13. Bob Wiyadabebe-Iytsaboi says:

    @Nick: Doesn't the time change for all people everywhere from each moment to the next, regardless of their location? ;-)

  14. Cesar says:

    @Darran Rowe: or two weeks ago ("Last DST change: DST began at Sáb 2015-10-17 23:59:59 BRT / Dom 2015-10-18 01:00:00 BRST")

  15. Using ZIP these days is a folly by itself. There is 7z and RAR.

    Microsoft has dumped ZIP in its update formats in favor of delta-compression scheme. Why not in Office documents and Windows itself? Well, it is not like I am waiting for Microsoft anyway.

  16. nikos says:

    here is a shell extension based on 7zip that does zipfolders (and 7z/rar folders) that appear to store the file date with better accuracy for windows explorer: (if created by 7zip in the first place)

    zabkat.com/.../compressed-folder-shell-extension.htm

  17. ErikF says:

    @Fleet Command: 7z and RAR are great compression schemes, but they lack the universality of ZIP. I can send anyone a ZIP file and be almost 100% certain that they will be able to extract files without having to acquire any other tool; I can't say the same thing about other formats. I'd love to use some other method (7z and BZIP2/XZ'd TAR files are my current favourites) but until they become super-popular the ZIP format is here to stay.

  18. Piotr says:

    @Fleet Command: „Microsoft has dumped ZIP in its update formats in favor of delta-compression scheme. Why not in Office documents and Windows itself?“

    Delta compression means sending the difference between an old and a new version. It's useless for office documents – you would have to send the original along, thus sending more data than before.

  19. @Piotr: It seems you've misunderstood the place of emphasis. The emphasis is on dumping not delta. i.e., they had the courage to dump the format in one place. They can do it in another. As another example of dumping ZIP, many of Microsoft self-extracting installers now employ 7z compression. Example: NDP46-KB3045557-x86-x64-AllOS-ENU.exe. (.NET Framework 4.6.)

    And the ZIP algorithm in Office documents is not exactly top notch. Recompress them with 7zip Manager (using ZIP compression!) and you get a better size with no compatibility loss. A 12 MB .docx file becomes 9 MB.

  20. 640k says:

    "If the file time went backward, then the freshen operation would always report that there were files that needed to be updated."

    No, not if you implemented logic to detect that case. But that's too hard I guess.

    And btw, a 64-bit OS year 2015 should *NOT* be compatible with 16-bit OS from early 80s.

  21. @640k: It is impossible to detect the logic because in doing so, a problem similar to "Did the egg come first or the  chick?" occurs. The 64-bit MAC time extension is the only real solution.

  22. cheong00 says:

    @Timothy Byrd: If softwares cannot ignore optional fields, we cannot have XML format.

  23. Engywuck says:

    @cheong00: there are dozens (or maybe hundreds, if counting internal ones) of unzip libraries, some of which go back to the early nineties. Can you garantee none of them will choke on this "extra field" (as it is called in ZIP documentation)? Sure, the concept of "extra field" was in ZIP since the first version, but I'm pretty sure there's at least one implementation of "that field's never used anyway". XML otoh is by definition optional field upon optional field -- and I've seen more than one handwritten parser choke when manually editing an otherwise automatically generated file and adding an extra field (or making a typo).

    Would it be nice if explorer would use this extra timestamp field upon extraction? Sure. But then you have an extra codepath just for this case, which means another test case for QA, plus at least some support calls -- and all this for an unusual case anyway.

  24. Steve says:

    The /FFT switch is also essential if you're robocopying files up from a local NTFS-format drive to your OneDrive.

  25. Brian says:

    @Fleet Command:

    Microsoft doesn't really own the Office formats anymore, the ISO does (ISO-29500).  You could wade through all of the (huge) ISO standard to see if better compression could be had without changing the standard.  I somehow doubt it.

  26. frenchguy says:

    @Engywuck: it is completely safe for Explorer to read these fields if they're present (they have been in existence for 15 years, so an extractor made in the last few years should definitely support them). The compatibility problems can only arise when creating archives (and writing the aforementioned fields).

    @Timothy Byrd: Non-conforming extractors can choke, for all I care. The only reservation I have is "Does any version of the specification allow an extractor to choke on an unknown extra field?" If it does, then Explorer shouldn't write those fields (to maintain compatibility).

  27. ErikF says:

    @640k: Why should a newer version of an OS introduce gratuitous incompatibilities with older versions for no good reason?

  28. Stefan Kanthak says:

    "Microsoft has dumped ZIP in its update formats in favor of delta-compression scheme."

    Wrong!

    Microsoft uses .CAB, not .ZIP, since 20 years, and both SetupAPI and MSI support it, directly/internally.

    Take a look at the installation media of Windows 9x, ME, NT4, 2000, XP and 2003. Or rename an .MSU to .CAB and double-click it.

    "As another example of dumping ZIP, many of Microsoft self-extracting installers now employ 7z compression."

    Have you but read their price tag"?

    It says VULNERABLE, good for an escalation of privilege!

    I prefer .MSI with an embedded .CAB (or .INF plus .CAB) about all these self-extracting installers: neither SetupAPI nor MSI have the vulnerabilities of ALL this self-extracting cruft.

  29. pkarc says:

    The Old New Thing, Time Machine Edition

    =======================================

    Why does my unzip utility crash when I try to extract files from a ZIP archive created by Windows Desktop Retro Edition XIV?

    10-30-2023 2:00PM

    Several years ago we saw that the timestamp of a file would increase by up to 2 seconds when you archived in a ZIP file using Windows Explorer. This was due to a limitation in Explorer's compression routines that supported only the legacy ZIP archive format of recording file times in MS-DOS format, making those time stamps subject to a two-second resolution limitation.

    In response to comments to that article, Explorer was updated to take advantage of optional fields in the ZIP specification that allow for time stamps in  NTFS format (64-bit MAC times).  ZIP programs that do not understand those optional fields are supposed to ignore them, in which case the MS-DOS time stamp (which is also required to be in the ZIP record for the file) would be used.

    However, it turns out that approximately 2% of the ZIP extraction utilities used in the real world crash upon encountering optional fields such as these.  Who would have guessed?  2% may not seem like a lot, but when your user base reaches into the tens of millions, that 2% can add up to a lot of support incidents.

    Bonus Chatter: Even people who have ZIP utilities that do not crash on encountering the option filed occasionally run into problems. For example one program might understand the NTFS formatted time stamp and act on it, while another program only deals with the MS-DOS formatted time stamp. This can result in the two programs repeatedly re-processing the file thinking that the one in the archive is incorrect due to mismatches with what each program thinks the time stamp of the archived file should be.

  30. frenchguy says:

    @pkarc: To fix the problem, install a conforming unzip utility (insert relevant links).

  31. morlamweb says:

    @frenchguy: and if the unzip tool is not a standalone program, but a library embedded in an application?  What should the user do in that scenario?  Updates for the unzip library may be available, or they may not; the developers may or may not be interested in updating their library, because it may mean rolling updates out to a large user base, for very little benefit.  If the MS-DOS timestamps in Zip files produced by Explorer bother you so much, then why not use a different compression tool?  You're not forced to use Explorer for file compression and decompression.

  32. RK says:

    Then preprocess your ZIP archives before passing them to the broken program linked against the broken library.

    I find it real funny for someone to demand that Explorer be frozen because they don't want to change and then immediately tell someone else to change their ways.  Just what do you think makes an old broken program more important than new programs that could benefit from a correction?  Some developers' lack of interest?  Because it sure isn't that these optional fields were sprung on them yesterday or defined in an incompatible manner.

  33. cheong00 says:

    @morlamweb: Same can be said when Microsoft decided to use Unicode filenames in Zip archive. IMO when they implement that, all resistance for changes that made before Unicode filename support (Zip format v6.3.0 published on 2006) are pointless.

  34. frenchguy says:

    @morlamweb: To be honest, I don't really need the extra precision in timestamps (and the MS-DOS timestamps are going to stay, since they're mandatory). But refusing to take advantage of newer features (especially if they have existed for 15 years) because it would break non-conforming programs is above and beyond maintaining compatibility (which is hard enough to do when it only involves conforming programs).

  35. morlamweb says:

    @cheong00: Explorer supports Unicode filenames; therefore, adding support for Unicode filenames to it's Zip compression/decompression routines would have enough importance to overcome the famous 100 point deficit for new features.  After all, users have the not-unreasonable expectation that file names, even Unicode ones, would survive a Zip compression & decompression round-trip intact.  A two-second or less difference in file times, however, would likely go unnoticed.

  36. cheong00 says:

    I mean, if you count the number of old Zip libraries that chokes when it see Zip files with Unicode filename entries to the number of Zip library that chokes when it see an extra field that is marked as optional in the standard on day 1, adding extra field is no big deal.

    Not to mention that in Zip format version 6.3.2 (2007), they decided to add InfoZip's way of handling Unicode filename into standard. (By using their way, instead of tweaking the language encoding bit for specify the filename is in UTF-8, they stored UTF-8 filename in extra field 0x7075 and store CP437 compatible filename (I assume that to be the filename in 8.3 format) in the original field)

  37. John says:

    Why complain about a 2 second difference? FAT and therefore zip doesn't support Daylight Savings Time either. So for about half the year anything zipped comes out shifted by a full hour (and up to 2 seconds).

  38. sense says:

    I, too, think the real argument is minus 100 points for implementing this feature.

    Implementing this feature leads to various QA scenarios, probable compatibility issues, possible support calls and much more trouble than anyone bothers. It works as is now, with near to no drawbacks.

Comments are closed.

Skip to main content