Wrong timestamp in RAR files modified in other time zone

[mikeyww]

You are both smart developers. From my perspective as a user, the current approach meets the definition of a bug-- software doing exactly what it was programmed to do, leading to an unanticipated and undesired effect for the user-- so I will remain hopeful that the TC Master will introduce a fix. If your question is why I care about the time displayed in the archive, the answer is that users often compare files (especially using TC's synchronize function), and an incorrect time will lead to a false conclusion that the files are different.

Thanks.

Mike

[ghisler(Author)]

So what do you suggest how TC should handle this? How can it recognize whether the timestamp was saved by RAR 4 or RAR 5 (local time vs. UTC)?

[mikeyww]

We probably need Eugene to reply with a suggestion. As for me, I am mostly concerned with how TC is using the packing (compression) function. I wonder if there is a way to determine the RAR format of archives that TC creates. If so, then it should also provide a way to accommodate that in displaying the files' correct times. At the moment, TC packs files and then shows the wrong times for the files that it packs. I do not know whether this type of fix is possible, but you might be able to advise about it. I believe that a fix is possible because WinRAR actually shows the right times for these files-- and so there is a way, and my understanding is that UnRAR is an open-source product. Eugene has also indicated, in his comments, the three-step process to get to the correct time. My understanding is that this does not involve directly knowing the RAR format, but instead using Microsoft calls to process the time correctly.

[Eugene_Roshal]

So what do you suggest how TC should handle this? How can it recognize whether the timestamp was saved by RAR 4 or RAR 5 (local time vs. UTC)?

Archives in RAR4 format (also known as RAR29) always store the local file time. If you apply the new time approach (3 functions) to archive created with WinRAR 5.01 and earlier, 1 hour error is possible. It does not happen always and it depends on file time, current time and daylight saving setting. WinRAR ignores this possible error and applies the new approach to all archives. I do not see many user complains about it, so I would recommend such approach.

Archives in RAR5 format store UTC file time and unrar.dll provides FILETIME in UTC format. You need to call FileTimeToSystemTime and SystemTimeToTzSpecificLocalTime to convert this FILETIME to SYSTEMTIME, not FileTimeToLocalFileTime and FileTimeToSystemTime. Like MS does here:
https://msdn.microsoft.com/en-us/library/windows/desktop/ms724926(v=vs.85).aspx

[mikeyww]

Thanks to Eugene. I agree with the suggestion.

Citing the MSDN link is problematic due to the characters in the link. The following one will work.

https://goo.gl/t3ZI2P

Mike

[MVV]

Not so problematic, but 100% transparent: https://msdn.microsoft.com/en-us/library/windows/desktop/ms724290.aspx.

BTW I don't think that it is correct to think that all RAR29 archives are created with latest WinRAR version and apply new time format. There are much more RAR29 archives created with old WinRAR versions than RAR29 archives created with WinRar 5+... And, there are much more old WinRAR versions that will read RAR29 archives and expect old time format. So it would be much more logical to use old time format scheme for all RAR29 archives, or at least set some header flag when new time format is used.

[mikeyww]

If no solution is perfect, perhaps we just need a configuration option to let the user toggle the approach to meet his or her specific needs.

Mike

[Eugene_Roshal]

Not so problematic, but 100% transparent: https://msdn.microsoft.com/en-us/library/windows/desktop/ms724290.aspx.

This link is certainly useful, but I meant the code sample at:
https://msdn.microsoft.com/en-us/library/windows/desktop/ms724926.aspx

BTW I don't think that it is correct to think that all RAR29 archives are created with latest WinRAR version and apply new time format.

I am not completely sure now, it is long time since I played with this part of code. But as far as I remember, the single function conversion approach can also introduce 1 hour error even for old archives depending on file time and current system time. I remember user complains about it and I think, this is why I started looking for alternative solutions. So if we use the new approach, everything is ok at least for new archives. If we use the old single function approach, we still can have 1 hour error even for old archives.

We can see the similar problem described here:
https://support.microsoft.com/en-us/help/129574/time-stamp-changes-with-daylight-savings
I suppose, it may be related to old style single function time conversion.

[MVV]

Well, perhaps you're right, timestamps saved in winter will be read incorrectly in summer and vice versa, so new time decoding scheme will only change season when time is read incorrectly...

[mikeyww]

At least at the moment, WinRAR's current approach is able to provide the correct file times for newly archived files, regardless of whether the files were saved in Daylight Savings Time.

Mike

[milo1012]

How can it recognize whether the timestamp was saved by RAR 4 or RAR 5 (local time vs. UTC)?

Actually we only mentioned the old rar 2.9 archive format until now, with the bug emerging from creating this format with WinRAR 5.1+ (and mikeyww providing the sample archive in this very format).
But now that you mentioned it: of course the same 1 hour error applies to the new rar5 format, due to the unrar interface not providing any additional information (just a FileTime).

I guess the only thing you actually CAN do is like I suggested before:
A new TC ini option for automatic adjustment, which the user enables if he thinks that most of his rar files were created with Rar 5.1+, sth. like
RarNewTimeMethod= 0/1

The question is, if it's worth it, as we already have the 1hourdif= ini option (which is global, though).

There are much more RAR29 archives created with old WinRAR versions than RAR29 archives created with WinRar 5+... And, there are much more old WinRAR versions that will read RAR29 archives and expect old time format. So it would be much more logical to use old time format scheme for all RAR29 archives, or at least set some header flag when new time format is used.

Yes, that's what I already implied. The new time conversion should have been applied to the new rar5 archive format only (where it makes sense, as it's a new format anyway), but leaving the old 2.9 format unaltered. But it doesn't matter anyway, as there doesn't seem to be any header flags (left) for this in the unrar interface. And even if it's added in a new rar/unrar version, the format already changed and so you probably have enough archives out there which are ambiguous for this timestamp issue.

[Eugene_Roshal]

But now that you mentioned it: of course the same 1 hour error applies to the new rar5 format, due to the unrar interface not providing any additional information (just a FileTime).

What additional information do you need for FILETIME in UTC format?

The new time conversion should have been applied to the new rar5 archive format only (where it makes sense, as it's a new format anyway), but leaving the old 2.9 format unaltered. But it doesn't matter anyway, as there doesn't seem to be any header flags (left) for this in the unrar interface.

How would such flag help if old style conversion still can produce 1 hour error for old archives. I mentioned it by few messages above. If you leave 2.9 unaltered, both old and new archives can be affected by 1 hour error.

[mikeyww]

The current ini option does not fix the issue, because it shifts the display of all file times.

I decided to check on how other file managers handle the RAR archives. Here is what I found.

• Showing correct times
  • Native display
    • FreeCommander XE 2017.740
    • MuCommander 0.9.1
  • Via running WinRAR
    • Xplorer2 3.3.0.2
    • XYplorer 17.00
• Showing incorrect times: Multi Commander 6.9.1.2306 (shifted 5 hours earlier)

So it seems that there is some hope, because two of these handle the archives correctly within the native display.

Mike

[MVV]

mikeyww,
If older format doesn't store DTS shift, no one archiver will ever be able to predict exact time that was at the moment of adding some file to archive...

[mikeyww]

We have acknowledged this at least twice so far. Our recommendation is for newer archives to show the correct times.

In case it helps, my current packer is WinRAR 5.31.0.

Mike