Declaration Syntax RemarksThis value corresponds to the "last modified" time in the NTFS file times as described in the Zip specification. When getting this property, the value may be different from LastModified. When setting the property, the LastModified property also gets set, but with a lower precision.
Let me explain. It's going to take a while, so get comfortable. Originally, waaaaay back in 1989 when the ZIP specification was originally described by the esteemed Mr. Phil Katz, the dominant operating system of the time was MS-DOS. MSDOS stored file times with a 2-second precision, because, c'mon, who is ever going to need better resolution than THAT? And so ZIP files, regardless of the platform on which the zip file was created, store file times in exactly the same format that DOS used in 1989.
Since then, the ZIP spec has evolved, but the internal format for file timestamps remains the same. Despite the fact that the way times are stored in a zip file is rooted in DOS heritage, any program on any operating system can format a time in this way, and most zip tools and libraries DO - they round file times to the nearest even second and store it just like DOS did 25+ years ago.
PKWare extended the ZIP specification to allow a zip file to store what are called "NTFS Times" and "Unix(tm) times" for a file. These are the last write, last access, and file creation times of a particular file. These metadata are not actually specific to NTFS or Unix. They are tracked for each file by NTFS and by various Unix filesystems, but they are also tracked by other filesystems, too. The key point is that the times are formatted in the zip file in the same way that NTFS formats the time (ticks since win32 epoch), or in the same way that Unix formats the time (seconds since Unix epoch). As with the DOS time, any tool or library running on any operating system is capable of formatting a time in one of these ways and embedding it into the zip file.
These extended times are higher precision quantities than the DOS time. As described above, the (DOS) LastModified has a precision of 2 seconds. The Unix time is stored with a precision of 1 second. The NTFS time is stored with a precision of 0.0000001 seconds. The quantities are easily convertible, except for the loss of precision you may incur.
A zip archive can store the {C,A,M} times in NTFS format, in Unix format, or not at all. Often a tool running on Unix or Mac will embed the times in Unix format (1 second precision), while WinZip running on Windows might embed the times in NTFS format (precision of of 0.0000001 seconds). When reading a zip file with these "extended" times, in either format, DotNetZip represents the values with the ModifiedTime, AccessedTime and CreationTime properties on the ZipEntry.
While any zip application or library, regardless of the platform it runs on, could use any of the time formats allowed by the ZIP specification, not all zip tools or libraries do support all these formats. Storing the higher-precision times for each entry is optional for zip files, and many tools and libraries don't use the higher precision quantities at all. The old DOS time, represented by LastModified, is guaranteed to be present, though it sometimes unset.
Ok, getting back to the question about how the LastModified property relates to this ModifiedTime property... LastModified is always set, while ModifiedTime is not. (The other times stored in the NTFS times extension, CreationTime and AccessedTime also may not be set on an entry that is read from an existing zip file.) When reading a zip file, then LastModified takes the DOS time that is stored with the file. If the DOS time has been stored as zero in the zipfile, then this library will use DateTime.Now for the LastModified value. If the ZIP file was created by an evolved tool, then there will also be higher precision NTFS or Unix times in the zip file. In that case, this library will read those times, and set LastModified and ModifiedTime to the same value, the one corresponding to the last write time of the file. If there are no higher precision times stored for the entry, then ModifiedTime remains unset (likewise AccessedTime and CreationTime), and LastModified keeps its DOS time.
When creating zip files with this library, by default the extended time properties (ModifiedTime, AccessedTime, and CreationTime) are set on the ZipEntry instance, and these data are stored in the zip archive for each entry, in NTFS format. If you add an entry from an actual filesystem file, then the entry gets the actual file times for that file, to NTFS-level precision. If you add an entry from a stream, or a string, then the times get the value DateTime.Now. In this case LastModified and ModifiedTime will be identical, to 2 seconds of precision. You can explicitly set the CreationTime, AccessedTime, and ModifiedTime of an entry using the property setters. If you want to set all of those quantities, it's more efficient to use the SetEntryTimes(DateTime, DateTime, DateTime) method. Those changes are not made permanent in the zip file until you call Save()()()() or one of its cousins.
When creating a zip file, you can override the default behavior of this library for formatting times in the zip file, disabling the embedding of file times in NTFS format or enabling the storage of file times in Unix format, or both. You may want to do this, for example, when creating a zip file on Windows, that will be consumed on a Mac, by an application that is not hip to the "NTFS times" format. To do this, use the EmitTimesInWindowsFormatWhenSaving and EmitTimesInUnixFormatWhenSaving properties. A valid zip file may store the file times in both formats. But, there are no guarantees that a program running on Mac or Linux will gracefully handle the NTFS-formatted times when Unix times are present, or that a non-DotNetZip-powered application running on Windows will be able to handle file times in Unix format. DotNetZip will always do something reasonable; other libraries or tools may not. When in doubt, test.
I'll bet you didn't think one person could type so much about time, eh? And reading it was so enjoyable, too! Well, in appreciation, maybe you should donate?