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: Mon, 04 Sep 2006 00:00:04 +0300 Message-ID: References: <44F4A8D0.6090304@gmx.at> <44F5D00D.5080409@gmx.at> <44F98B06.2020602@gmx.at> <44FAB10B.8010608@gmx.at> Reply-To: Eli Zaretskii NNTP-Posting-Host: main.gmane.org X-Trace: sea.gmane.org 1157317237 29059 80.91.229.2 (3 Sep 2006 21:00:37 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Sun, 3 Sep 2006 21:00:37 +0000 (UTC) Cc: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Sep 03 23:00:34 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 1GJz4s-0006lN-Cz for ged-emacs-devel@m.gmane.org; Sun, 03 Sep 2006 23:00:26 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1GJz4r-0003gg-W7 for ged-emacs-devel@m.gmane.org; Sun, 03 Sep 2006 17:00:26 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1GJz4h-0003gR-6e for emacs-devel@gnu.org; Sun, 03 Sep 2006 17:00:15 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1GJz4d-0003gF-Ey for emacs-devel@gnu.org; Sun, 03 Sep 2006 17:00:13 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1GJz4d-0003gC-AO for emacs-devel@gnu.org; Sun, 03 Sep 2006 17:00:11 -0400 Original-Received: from [199.232.41.67] (helo=mx20.gnu.org) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA:32) (Exim 4.52) id 1GJzF0-0006qk-9D for emacs-devel@gnu.org; Sun, 03 Sep 2006 17:10:54 -0400 Original-Received: from [192.114.186.20] (helo=nitzan.inter.net.il) by mx20.gnu.org with esmtp (Exim 4.52) id 1GJz4c-0003sC-7i for emacs-devel@gnu.org; Sun, 03 Sep 2006 17:00:10 -0400 Original-Received: from HOME-C4E4A596F7 (IGLD-84-228-143-113.inter.net.il [84.228.143.113]) by nitzan.inter.net.il (MOS 3.7.3-GA) with ESMTP id EOE23885 (AUTH halo1); Mon, 4 Sep 2006 00:00:05 +0300 (IDT) Original-To: martin rudalics In-reply-to: <44FAB10B.8010608@gmx.at> (message from martin rudalics on Sun, 03 Sep 2006 12:40:11 +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:59293 Archived-At: > Date: Sun, 03 Sep 2006 12:40:11 +0200 > From: martin rudalics > CC: emacs-devel@gnu.org > > > I use some old port of CVS, and it does have problems when > > DST changes, even though I have an XP machine and an NTFS filesystem. > > So I think the CVS port does have a say here, not only the filesystem. > > Maybe it's related to what I read here > > http://www.codeproject.com/datetime/dstbugs.asp This one partly describes what the MSDN article whose URL I posted describes, and partly is simply wrong. There _is_ a way of correctly accounting for DST on NTFS, and the MSDN article says how to do that. Presumably, library functions on Windows do that already, although I didn't have time to check. > and there > > http://www.devguy.com/fp/cfgmgmt/cvs/ This seems to say that WinCVS figured out how to code around the problem for FAT, but not for NTFS. > > What I did was to reset the time zone to GMT and disable the automatic > > DST corrections, then look at what DIR (from cmd.exe) reports. I then > > set the time zone back to the normal setting, and looked at what DIR > > displayed now. > > Did you change your local time in the BIOS? Did you change the time > zone settings in > > HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\TimeZoneInformation\ > > Or did you simply check the box about automatic correction from the > system tray? The latter. > That just dis-/enables setting local time after the first > start of Windows when DST has changed by consulting > > HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Time Zones\ Note that I changed to GMT+0 _and_ disabled automatic DST correction. Thus, no additional registry changes are necessary, at least not on XP. > My settings for this are > > C4 FF FF FF 00 00 00 00 > C4 FF FF FF 00 00 0A 00 <-- 0A means "october" > 00 00 05 00 03 00 00 00 <-- 05 means last sunday, 03 at three o'clock > 00 00 00 00 00 00 03 00 <-- 03 means "march" > 00 00 05 00 02 00 00 00 <-- 05 means last sunday, 02 at two o'clock > 00 00 00 00 > > Did you change that? GMT+0/no DST means the DST rules have no effect. > I have checked the box on the present partition and disabled it on all > other partitions. Otherwise I'd change my local time whenever I switch > to another partition after DST changed. (Un-)checking the box does not > have any impact on how file modification times are reported. Because you are on a FAT volume. > > My conclusion was that DIR lies about file times: it > > reports them as if DST were in effect, even if the file was modified > > when DST was off. > > Because you neither changed your local time nor the respective registry > settings, I presume. Local time changes automatically on XP when you change the time zone (my PC synchronizes with a time server via NTP, if that matters). > My ls.exe (version 3.16 of GNU fileutils) doesn't report full time for > files modified before March, 9th, 2006 - for whatever reason. That's the standard ls ``6 months is way in the past'' policy. It only displays full time for files modified ``recently''. > However, > the times reported by ls for files last modified around March 15, 2006 > match those reported by DIR and other applications. They are _not_ > identic to those reported by Emacs' file-attributes. I think file-attributes returns UTC times, since it calls `stat'. > But do ls.exe and DIR give the same information for src/unexelf.c on > your system? I thought I explained that DIR reports it with a 1-hour error, due to incorrect accounting for DST. > And what would interest me most: Could you try to debug > `vc-cvs-parse-entry' while opening src/unexelf.c and look whether it > classifies the file as modified? I will try when I have time, but I doubt it will be marked modified. > > http://www.digital-detective.co.uk/freetools/decode.asp > > What values do you paste there? Where do you get them from? It accepts values from `stat' or similar API functions.