Hello!
\r\nI noticed that timestamps for zimEntries in my ZipFile instance are not correct. Here is the code I am using to zip a directory:
\r\n<font size="2" color="#0000ff"><font size="2" color="#0000ff">\r\n using
(ZipFile zip = new ZipFile())
\r\n{
\r\nzip.AddDirectory(path);
\r\nMemoryStream memoryStream = new MemoryStream();
\r\n}
\r\nin the debugger, I can see the timestamp values for one of the Entries that look like this:
\r\n\r\nCtime {8/13/2009 7:47:36 PM} System.DateTime
\r\nLastModified {8/13/2009 3:47:36 PM} System.DateTime
\r\nMtime {8/13/2009 7:47:36 PM} System.DateTime
\r\nOnly the LastModified field has the timestamp that is close to the actual timestamp of the file. It is not clear to me why Mtime and Ctime are shifted by 4 hrs? Also the timestamp for LastModified seems to be rounded and doesn't exactly match the timestamp of the file. So, the comparison of timestamps will not work properly.
\r\nDoes anyone have any suggestion on how to work around this issue?
\r\nThanks,
\r\nNorton.
\r\n", "PostedDate": "2009-08-13T13:19:37.907-07:00", "UserRole": null, "MarkedAsAnswerDate": null }, { "Id": "223112", "ThreadId": "65509", "Html": "
This is my favorite topic!
\r\nI kid. It's been very tricky for me to get the timestamps to work properly.
\r\nBut your problem is simple. LastModified is expressed in LocalTime, while Ctime and Mtime are in UTC. They are all the same point in time.
\r\nThe rounding is a side effect of the way the zip format stores timestamps. If you want to compare LastModified to another time, you'll need to compare the delta. In other words, subtract the time on the file from another time, and then compare that difference (which is a TimeSpan) to a fixed TimeSpan. If you are using the LastModified time, the precision is 2 seconds, so you will need to compare to a TimeSpan of 2 seconds.
\r\nIf you use Mtime or Ctime, then the comparison is exact. These numbers are stored differently in the zip file, stored with the full precision of the NTFS filesystem. But if the zip file was created on a non-NTFS system, then you probably have to revert to the delta approach again. It's safest to just use the delta approach in all cases.
\r\nCheck the doc on these properties for more info.
\r\n", "PostedDate": "2009-08-13T13:57:08.167-07:00", "UserRole": null, "MarkedAsAnswerDate": null }, { "Id": "223564", "ThreadId": "65509", "Html": "\r\n
From: Cheeso
\r\nThis is my favorite topic!
\r\nI kid. It's been very tricky for me to get the timestamps to work \r\nproperly.
\r\nBut your problem is simple. LastModified is expressed in LocalTime, \r\nwhile Ctime and Mtime are in UTC. They are all the same point in \r\ntime.
\r\nThe rounding is a side effect of the way the zip format stores \r\ntimestamps. If you want to compare LastModified to another time, you'll \r\nneed to compare the delta. In other words, subtract the time on the file \r\nfrom another time, and then compare that difference (which is a TimeSpan) to a \r\nfixed TimeSpan. If you are using the LastModified time, the precision \r\nis 2 seconds, so you will need to compare to a TimeSpan of 2 seconds.
\r\nIf you use Mtime or Ctime, then the comparison is exact. These numbers \r\nare stored differently in the zip file, stored with the full precision of \r\nthe NTFS filesystem. But if the zip file was created on a non-NTFS \r\nsystem, then you probably have to revert to the delta approach again. It's \r\nsafest to just use the delta approach in all cases.
\r\nCheck the doc on these properties for more info.
\r\n