From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: martin rudalics Newsgroups: gmane.emacs.devel Subject: Re: vc-cvs-parse-entry Date: Sat, 02 Sep 2006 15:45:42 +0200 Message-ID: <44F98B06.2020602@gmx.at> References: <44F4A8D0.6090304@gmx.at> <44F5D00D.5080409@gmx.at> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Trace: sea.gmane.org 1157204787 10735 80.91.229.2 (2 Sep 2006 13:46:27 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Sat, 2 Sep 2006 13:46:27 +0000 (UTC) Cc: monnier@iro.umontreal.ca, emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Sep 02 15:46:24 2006 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1GJVpD-0003Dp-6G for ged-emacs-devel@m.gmane.org; Sat, 02 Sep 2006 15:46:19 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1GJVpC-0002nk-P4 for ged-emacs-devel@m.gmane.org; Sat, 02 Sep 2006 09:46:18 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1GJVp1-0002kz-A9 for emacs-devel@gnu.org; Sat, 02 Sep 2006 09:46:07 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1GJVoy-0002ec-Fs for emacs-devel@gnu.org; Sat, 02 Sep 2006 09:46:07 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1GJVoy-0002eK-AY for emacs-devel@gnu.org; Sat, 02 Sep 2006 09:46:04 -0400 Original-Received: from [213.165.64.20] (helo=mail.gmx.net) by monty-python.gnu.org with smtp (Exim 4.52) id 1GJVz3-0007Mj-0M for emacs-devel@gnu.org; Sat, 02 Sep 2006 09:56:29 -0400 Original-Received: (qmail invoked by alias); 02 Sep 2006 13:46:02 -0000 Original-Received: from N880P027.adsl.highway.telekom.at (EHLO [62.47.53.251]) [62.47.53.251] by mail.gmx.net (mp030) with SMTP; 02 Sep 2006 15:46:02 +0200 X-Authenticated: #14592706 User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: de-DE, de, en-us, en Original-To: Eli Zaretskii In-Reply-To: X-Y-GMX-Trusted: 0 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:59254 Archived-At: >>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.