#1645 Some zipped files have wrong timestamp by one hour

[Jiffy Space]

I have some strange behavior here. I have two files with last changed timestamp 03.12.2009 13:10 and the other one with 27.08.2009 18:47. The one with 18:47 is shown with timestamp 17:47 after zipped with 7-zip in zip format, the other one is correctly shown with timestamp 13:10 after zipped with 7-zip in zip-format. When unzipped both files have the correct timestamp again. So it seems 7-zip is just showing a wrong timestamp for some files in the file manager.

[Igor Pavlov]

There are many things:
1) daylight time changes
2) file sysytem (FAT / NTFS)
3) the program that was used to extract from archive

7-Zip uses UTC timestamp and simplified function that uses corrent timezone offset to show old timestams
New versions of Windows has special code that tries to show correct local time for old timestamps. That function probably "knows" about all time changes in past.

Maybe 7-Zip must use that new function too. But I'm not sure that it's good in 100% cases, since it can change some things that work OK now.

[Bart Joy]

We're noticing the same problem. I have looked in the code, and notice that you use the FileTimeToLocalFileTime API in your PrintTime function. MSDN has the following remarks about this API:

To account for daylight saving time when converting a file time to a local time, use the following sequence of functions in place of using FileTimeToLocalFileTime
1. FileTimeToSystemTime
2. SystemTimeToTzSpecificLocalTime
3. SystemTimeToFileTime

The inverse function (LocalFileTimeToFileTime) has the following remarks:

LocalFileTimeToFileTime uses the current settings for the time zone and daylight saving time. Therefore, if it is daylight saving time, this function will take daylight saving time into account, even if the time you are converting is in standard time.

I've attached a screenshot that shows:

• PowerShell listing (PowerShell runs on .NET). This shows the correct UTC file time. It also shows the correct local time (12 hour offset for NZST with no daylight savings).
• cmd.exe directory listing. I assume that this uses the same API as 7z, because it shows the wrong local time due to applying a 13 hour offset (NZDT), which is because we are currently in daylight savings in New Zealand. The file was created at a time when daylight savings was not in effect.
• 7za.exe listing, which shows the same file at the bottom of the listing with the incorrect time.

Why New Zealand persists with daylight savings is an annoyance outside the scope of this bug report.