#46 Incorrect dateTime.

v1.0_(example)
closed-fixed
nobody
None
5
2014-02-16
2014-02-08
TeHe
No

QuaZipFileInfo.dateTime returns a incorrect value, margin of error (on my machine) is between 0-2000ms.

To replicate this problem, I am using the getFileInfoList() function to read all the files inside the archive, then simply read all the values(dateTime) in QList<QuaZipFileInfo>.

Discussion

  • Sergey A. Tachenov

    2 seconds is the precision with which the date and the time are stored in the ZIP format. It is rounded down by minizip. I could round it to the nearest 2 seconds, thus giving the margin of error -1000-+1000, which would mean that the absolute error would be no larger than 1 second instead of 2, but in this case the date could be wrong. Suppose the file is created on Jan 1 23:59:59.600 - that would be rounded to Jan 2 midnight. The way it is now rounds to Jan 1 23:59:58.000 - at least the date stays the same.

     
  • TeHe

    TeHe - 2014-02-08

    Does that mean that the margin of error won't exceed the 2s on all the machines?
    I noticed that some software (as 7-zip) shows the correct dates of the files inside the archive. Do they use some trick or it's actually possible to calculate it fast on the spot? I need the exact dates (with the precision to the second) for my project.

     
  • Sergey A. Tachenov

    Yes, on all machines it's the same. Here is the relevant code:

      (uLong) (((ptm->tm_mday) + (32 * (ptm->tm_mon+1)) + (512 * year)) << 16) |
        ((ptm->tm_sec/2) + (32* ptm->tm_min) + (2048 * (uLong)ptm->tm_hour));
    

    Now, the fact is that some third-party software is actually able to show the correct times mean that there is some sort of extension to the ZIP format that allows to store more precise timestamps. I'll look into it, and if it's not too complicated, implement this too.

    It's impossible to literally calculate it, though, as it's not stored in the archive. I'll need to find some way to store it first.

     
  • TeHe

    TeHe - 2014-02-09

    Thank you for explaining it to me.
    I hope that you will manage to do something in that matter. It would be really handy.

     
  • Sergey A. Tachenov

    OK, I've figured this one out. There is an optional structure in the extra field which contains NTFS times - modification, access, creation. I've yet to implement storing these, but I've already implemented reading them. The SVN trunk now contains this code. Use getNTFSmTime() method on QuaZipFileInfo64 (no analog for QuaZipFileInfo since it is provided only for compatibility). If there is no NTFS time in the ZIP archive, this method will return an invalid QDateTime, so you must fall back to the dateTime field in such case. If you need more than milliseconds, you can also pass an int pointer to the method, which will contain microseconds and 10th of microseconds (MS ticks).

    I'll work on writing the times in the ZIP archives now.

     
  • Sergey A. Tachenov

    Implemented writing those fields too in r223. QuaZipNewInfo::setFileNTFSTimes() is the easiest way, more specific methods for each time are provided too. Tests added to the test suite, and everything seems to be working fine now.

     
  • Sergey A. Tachenov

    • status: open --> pending-fixed
     
  • TeHe

    TeHe - 2014-02-15

    Thank you so much! It's working perfectly!

     
  • Sergey A. Tachenov

    • status: pending-fixed --> closed-fixed
     
  • Sergey A. Tachenov

    You're welcome. The ticket is closed.

     

Log in to post a comment.

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

JavaScript is required for this form.





No, thanks