Re: vc-cvs-parse-entry

[martin rudalics]

>>Note that if more recent versions of w32 fixed this problem, it should be
>>fixed for both CVS and vc-cvs.el (and pcl-cvs ;-).
>
>
> Only if the CVS client uses the right code to get the file times; see
> the above URL for the gory details.

FWIW, CVS did "use the right code to get the file times".  Also files
reported by vc-cvs-parse-entry as "modified" are _not_ reported as
"modified" by a recently installed wincvs.  In fact. I've not been able
to reproduce the modification times reported by (X)Emacs with any other
application on my system.

> However, for a valid and meaningful comparison, the test cases you've
> chosen are not good enough.  First, the actual time stamps of files in
> the local sandbox depend on the exact day one checks out the CVS tree
> and/or resyncs with it.  Obviously, no two people do that on the same
> day; for example, my CVS tree was checked out in June 2005, so
> acldef.h bears a time stamp of June 18, 2005, which is very different
> from yours.  It's impossible to compare times like this.

I see: These two files are among the few that had not been changed ever
since I checked out my CVS tree.  Hence there was a minimal chance it
would be the same for you.

> I don't have any suggestions for how to make a meaningful comparison,
> though.  There are too many system calls involved, and too many
> unknowns.

Provided DST is on in your current time zone: Do you have a file on your
system with a modification date while DST was off?  Does your OS give
the same modification time as Emacs?  It doesn't for me.  Reading the
URL you suggested I think it's due to the following:

FindFirstFile retrieves the local time from the FAT file system and
converts it to UTC by using the current settings for the time zone and
daylight saving time. Therefore, if it is daylight saving time,
FindFirstFile takes daylight saving time into account, even if the file
time you are converting is in standard time.