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: Sun, 10 Sep 2006 11:55:33 +0200 Message-ID: <4503E115.4020206@gmx.at> References: <44F4A8D0.6090304@gmx.at> <44F5D00D.5080409@gmx.at> <44F98B06.2020602@gmx.at> <44FAB10B.8010608@gmx.at> <44FBEF1E.8030806@gmx.at> <44FD3EFC.9040603@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 1157883050 12796 80.91.229.2 (10 Sep 2006 10:10:50 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Sun, 10 Sep 2006 10:10:50 +0000 (UTC) Cc: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Sep 10 12:10:48 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 1GMMGs-00085P-EX for ged-emacs-devel@m.gmane.org; Sun, 10 Sep 2006 12:10:38 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1GMMGr-0002hS-La for ged-emacs-devel@m.gmane.org; Sun, 10 Sep 2006 06:10:37 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1GMMGD-0002IQ-2w for emacs-devel@gnu.org; Sun, 10 Sep 2006 06:09:57 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1GMMGB-0002G0-31 for emacs-devel@gnu.org; Sun, 10 Sep 2006 06:09:56 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1GMMGA-0002Fj-I0 for emacs-devel@gnu.org; Sun, 10 Sep 2006 06:09:54 -0400 Original-Received: from [213.165.64.20] (helo=mail.gmx.net) by monty-python.gnu.org with smtp (Exim 4.52) id 1GMMHB-0005nS-Ir for emacs-devel@gnu.org; Sun, 10 Sep 2006 06:10:57 -0400 Original-Received: (qmail invoked by alias); 10 Sep 2006 10:09:51 -0000 Original-Received: from N730P022.adsl.highway.telekom.at (EHLO [62.47.35.54]) [62.47.35.54] by mail.gmx.net (mp037) with SMTP; 10 Sep 2006 12:09:51 +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:59619 Archived-At: > The server times have nothing to do with this: the files on your > machine get timestamped with your machine's time when they are updated > by "cvs up". The two files in question were never affected by a cvs update after I checked that out in early 2005. Earlier you wrote: > How about src/unexelf.c, for example? It has the > modification time of March 18, 2006, 5:32PM on my system. According to your reasoning above wouldn't this imply you never did a cvs update after March 2006? > One simple way of figuring out whether Emacs lies about time-related > values is to reset your machine's date to when DST is not in effect, > create a file (noting what was the machine's wallclock time), then > revert the date to its correct value, and perform the experiments with > that file. (It is best to reboot the machine each time you modify the > date.) Can you try that? I wouldn't know what to reset. I'm reluctant to change DST settings in the registry. (Un-)checking that box from the system tray affects the behavior of my machine only when DST actually changes. Changing the time-zone settings of my machine won't affect filetimes and how they are displayed (it might affect cvs update, though). Note: For a computer that never moves from one time-zone to another it's insignificant whether modification times are stored as UTC or local time. It's sufficient to maintain a set of rules that determine whether a modification time has to be evaluated with DST on or off. In my present time-zone the respective dates are the last sundays in March and October of a year. Getting the correct modification time of a file must be done by adding one hour to the modification time stored on disk provided that time falls somewhere between these dates for the year in question. Obviously, for one hour each year, a file B I modified after a file A will get an earlier modification time than A. Since I don't work at that time I never noticed that problem. Clearly, the "storing local times only" philospohy must fail when I move my machine from one time-zone to another: I cannot distinguish files created in different time-zones since I have no notion of UTC. Every interpretation of a filetime occurs as if the file had been modified in my present (virtual) time-zone. > But you didn't compare the result of file-attributes, you compared the > result of running file-attributes' value through format-time-string, > which converts the value to local time. We need to separate these two > unknowns, I think. On my system `file-attributes' represent local time. >>ls (GNU coreutils) 5.3.0 does the same as stat (GNU coreutils) 5.3.0. >>I conjecture that both report wrong times for Windows98/FAT32. > > This comes as no surprise, since no doubt _all_ programs in the ported > Coreutils, including stat, were linked against the same implementation > of the library function `stat'. I suppose they changed that for XP and simply forgot about FAT Windows. In fact, installing the latest GnuWin32 also broke something in building Emacs on my machine (probably due to a change in cp.exe). It took me some time to restore my fragile balance of mingw, cygwin, unxutils and gnuwin32 tools after that.