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: Wed, 30 Aug 2006 15:24:04 +0300 Message-ID: References: <44F4A8D0.6090304@gmx.at> Reply-To: Eli Zaretskii NNTP-Posting-Host: main.gmane.org X-Trace: sea.gmane.org 1156940678 24516 80.91.229.2 (30 Aug 2006 12:24:38 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Wed, 30 Aug 2006 12:24:38 +0000 (UTC) Cc: rudalics@gmx.at, emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Aug 30 14:24:35 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 1GIP7J-00061b-1D for ged-emacs-devel@m.gmane.org; Wed, 30 Aug 2006 14:24:25 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1GIP7I-0003bu-GN for ged-emacs-devel@m.gmane.org; Wed, 30 Aug 2006 08:24:24 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1GIP78-0003bj-Nu for emacs-devel@gnu.org; Wed, 30 Aug 2006 08:24:14 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1GIP76-0003b7-Q0 for emacs-devel@gnu.org; Wed, 30 Aug 2006 08:24:14 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1GIP76-0003b4-Hg for emacs-devel@gnu.org; Wed, 30 Aug 2006 08:24:12 -0400 Original-Received: from [192.114.186.66] (helo=romy.inter.net.il) by monty-python.gnu.org with esmtp (Exim 4.52) id 1GIPGU-0005nb-TL for emacs-devel@gnu.org; Wed, 30 Aug 2006 08:33:55 -0400 Original-Received: from HOME-C4E4A596F7 (IGLD-80-230-205-199.inter.net.il [80.230.205.199]) by romy.inter.net.il (MOS 3.7.3-GA) with ESMTP id FPT60961 (AUTH halo1); Wed, 30 Aug 2006 15:24:05 +0300 (IDT) Original-To: Stefan Monnier In-reply-to: (message from Stefan Monnier on Tue, 29 Aug 2006 17:06:50 -0400) 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:59109 Archived-At: > From: Stefan Monnier > Date: Tue, 29 Aug 2006 17:06:50 -0400 > Cc: emacs-devel@gnu.org > > >> What system is that (w32?)? > > In GNU Emacs 22.0.50.1 (i386-mingw-windows98.3000) > > Then it's a known problem that's pretty hard to fix: > > w32 handles DST by changing the definition of "time 0" This is not really accurate, at least on newer versions of Windows; see below. > so during the DST-change things behave as if all the files's > timestamps had been changed by 1 hour. > > So there really is a 1-hour difference between what the CVS/Entries file > says and what the file's time stamp says. We could try to be more clever > with such situations, but since it's basically a case of braindamage in the > w32 "spec" I'd rather not bother. I'm not familiar with the details, nor with vc-cvs in general, so what's below might be nonsense; sorry if so. Is the problem you describe above in Emacs or in the CVS client that Emacs runs? If the latter, I agree that some (or maybe all) Windows ports of the CVS client don't DTRT in this case. If this is the problem, the only way to fix it is to complain to the maintainer(s) of the CVS port and maybe provide a patch to them. However, if the problem is in Emacs, we might be able to fix it, if someone describes what Emacs functions are involved. This is because Windows does maintain the DST change rules, and its implementation of localtime is supposed to use those rules, if they are known to the OS, when it computes the tm_isdst member of struct tm. So, at least in principle, the required information is available, and can be used to DTRT in this case. For example, in the GnuWin32 port of Diffutils, I see that the file times are reported with correct TZ offsets, like this: --- make.h~0 2006-02-16 03:54:43.000000000 +0200 +++ make.h 2006-08-18 21:12:32.859375000 +0300 As you see, Diff correctly determines that the old version was before the DST change, while the new was after it. AFAICS, Diff uses strftime (which in turn uses localtime) to get at this information. > IIRC "cvs update" will fix things for you. Yes, but it's _awfully_ slow. I needed to write a program to move the files' last write timestamp by N hours, to avoid the resultant lossage on Windows, whereby "cvs up" after a DST change can take _hours_ because each file is sent upstream due to the time mismatch. Again, sorry if what I said doesn't make sense in the context of this discussion.