From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: vc-cvs-parse-entry Date: Tue, 05 Sep 2006 21:31:27 +0300 Message-ID: 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> Reply-To: Eli Zaretskii NNTP-Posting-Host: main.gmane.org X-Trace: sea.gmane.org 1157481125 28988 80.91.229.2 (5 Sep 2006 18:32:05 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Tue, 5 Sep 2006 18:32:05 +0000 (UTC) Cc: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Sep 05 20:32:03 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 1GKfi3-0005xt-Fe for ged-emacs-devel@m.gmane.org; Tue, 05 Sep 2006 20:31:43 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1GKfi3-0004NN-0X for ged-emacs-devel@m.gmane.org; Tue, 05 Sep 2006 14:31:43 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1GKfhq-0004MA-Uk for emacs-devel@gnu.org; Tue, 05 Sep 2006 14:31:30 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1GKfhp-0004KO-C2 for emacs-devel@gnu.org; Tue, 05 Sep 2006 14:31:30 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1GKfhp-0004K7-70 for emacs-devel@gnu.org; Tue, 05 Sep 2006 14:31:29 -0400 Original-Received: from [192.114.186.20] (helo=nitzan.inter.net.il) by monty-python.gnu.org with esmtp (Exim 4.52) id 1GKfsc-0003Bo-KX for emacs-devel@gnu.org; Tue, 05 Sep 2006 14:42:38 -0400 Original-Received: from HOME-C4E4A596F7 (IGLD-83-130-5-95.inter.net.il [83.130.5.95]) by nitzan.inter.net.il (MOS 3.7.3-GA) with ESMTP id EOO54797 (AUTH halo1); Tue, 5 Sep 2006 21:31:27 +0300 (IDT) Original-To: martin rudalics In-reply-to: <44FD3EFC.9040603@gmx.at> (message from martin rudalics on Tue, 05 Sep 2006 11:10:20 +0200) 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:59384 Archived-At: > Date: Tue, 05 Sep 2006 11:10:20 +0200 > From: martin rudalics > CC: emacs-devel@gnu.org > > > Please tell which of these results are correct. I don't know what are > > the details of the DST rules in your locale. > > I can't. I don't know how to get the original times from the server. 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". 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? > Hence I strongly conjecture that when DST is on, `file-attributes' > returns the wrong modification time for files saved when DST was off for > Windows98/FAT32. 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. > >>BTW, stat (GNU coreutils) 5.3.0 gives the same results as Emacs, hence > >>the results delivered by stat and ls (GNU fileutils) 3.16 differ on my > >>system. > > > > > > The GnuWin32 ports use a different implementation of stat nowadays, > > perhaps that's the cause for the different results. > > 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'.