#1996 Wrong time stamp even in latest revision (NOT old bug)

Trunk
closed-fixed
Jochen Tucht
5
2010-06-19
2010-04-07
SimCutie
No

I have read "Wrong Timestamps in Generaged Patch - ID: 2791506" bug report and it says that the bug is fixed. (status: closed) But even in latest experimental release ( Version 2.13.11 Unicode ), the bug persists.

It works correctly on generating diff of two explicitly selected individual files. (Select two time, do a diff, make a patch)
But it does not work correctly on file comparison of a pair of directories. I select two directories, diff them, and select few files with difference, and then go Menu: "Tools">>"Generate Patch", selected Unified diff as diff style and generate a patch. This is how the generated diff file looks like:

BEGIN ------------------------------
diff U5 readme.txt readme.txt
--- readme.txt Fri Sep 11 12:22:32 1970
+++ readme.txt Fri Sep 11 12:22:32 1970
@@ -7,10 +7,12 @@
or otherwise significant changes. Subversion commit messages provide a
detailed changelog for all the changes. Commit messages also have a
SourceForge.net tracker number mentioned when the commit is related to
one of the tracker items.

+THIS IS NEW LINE
+
Subfolders include:

- Docs
Both user and developer documentation, in different subfolders.
Can be browsed by opening index.html in Docs folder.

END ----------------------------------------------

You see all the time stamp of the files are around 1970 and both are same.
But actually, they have different time stamps and not year 1970, of course.
The wrong time stamp itself varies depending on the time when the "patch" is generated,
even on same pair of files, NOT the file mod/creation time of these files.

I use WinMerge rel. 2.13.11 Unicode version on Windows 7 Home (Korean).

Discussion

  • Kimmo Varis
    Kimmo Varis
    2010-06-13

    Can you check what Explorer says about dates of those files. In Windows there are three types of dates for each file:
    - created
    - last modified
    - last accessed

    And there's been problems that it seems to be pretty random which of those exist and are properly updated to what user expects. If one is missing and we want to use it then the date becomes this 1970...

     
  • Jochen Tucht
    Jochen Tucht
    2010-06-13

    Completed: At revision: 7189

     
  • Kimmo Varis
    Kimmo Varis
    2010-06-19

    • assigned_to: nobody --> jtuc
    • milestone: 438016 --> Trunk
    • status: open --> closed-fixed
     
  • Kimmo Varis
    Kimmo Varis
    2010-06-19

    Fixed in WinMerge 2.13.13 experimental version.