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: Sat, 02 Sep 2006 17:48:15 +0300 Message-ID: References: <44F4A8D0.6090304@gmx.at> <44F5D00D.5080409@gmx.at> <44F98B06.2020602@gmx.at> Reply-To: Eli Zaretskii NNTP-Posting-Host: main.gmane.org X-Trace: sea.gmane.org 1157208530 21046 80.91.229.2 (2 Sep 2006 14:48:50 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Sat, 2 Sep 2006 14:48:50 +0000 (UTC) Cc: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Sep 02 16:48:47 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 1GJWnW-00069S-EL for ged-emacs-devel@m.gmane.org; Sat, 02 Sep 2006 16:48:39 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1GJWnV-0007pR-Si for ged-emacs-devel@m.gmane.org; Sat, 02 Sep 2006 10:48:37 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1GJWnF-0007mu-5C for emacs-devel@gnu.org; Sat, 02 Sep 2006 10:48:21 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1GJWnE-0007lR-7p for emacs-devel@gnu.org; Sat, 02 Sep 2006 10:48:20 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1GJWnE-0007lA-0d for emacs-devel@gnu.org; Sat, 02 Sep 2006 10:48:20 -0400 Original-Received: from [192.114.186.73] (helo=heller.inter.net.il) by monty-python.gnu.org with esmtp (Exim 4.52) id 1GJWxJ-0003z1-0c for emacs-devel@gnu.org; Sat, 02 Sep 2006 10:58:45 -0400 Original-Received: from HOME-C4E4A596F7 (IGLD-80-230-70-232.inter.net.il [80.230.70.232]) by heller.inter.net.il (MOS 3.7.3a-GA) with ESMTP id AJC33854 (AUTH halo1); Sat, 2 Sep 2006 17:48:17 +0300 (IDT) Original-To: martin rudalics In-reply-to: <44F98B06.2020602@gmx.at> (message from martin rudalics on Sat, 02 Sep 2006 15:45:42 +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:59258 Archived-At: > Date: Sat, 02 Sep 2006 15:45:42 +0200 > From: martin rudalics > CC: monnier@iro.umontreal.ca, emacs-devel@gnu.org > > >>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". By ``CVS'', do you mean ``the recently installed wincvs'' you mentioned? 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. > In fact. I've not been able to reproduce the modification times > reported by (X)Emacs with any other application on my system. Please show an example of these modification times, and how did you compare that with whatever other applications on your system report file times. > 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? Yes, of course. How about src/unexelf.c, for example? It has the modification time of March 18, 2006, 5:32PM on my system. > Does your OS give the same modification time as Emacs? The problem is with the ``OS'' part--how did you know what ``the OS'' thinks about that file's times? What utilities/system calls and/or Emacs functions you used to find that out? I don't think we can have any progress until we have answers for these questions, and understand well what code is involved in reporting time stamps. One problem is that, for commands like DIR, we don't have any way of knowing what they do, since their source code is not available. 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. 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. By contrast, the GnuWin32 port of ls.exe reported the file times correctly, both for files modified under DST and files modified outside DST. We could make a similar check with Emacs primitives instead of ls.exe and DIR, if needed. But the trick with setting TZ to GMT probably won't work on FAT volumes, since the file times are recorded as local time there. Btw, I find the Date/Time decoder utility very useful when testing these issues, see: http://www.digital-detective.co.uk/freetools/decode.asp > 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. It's possible. You might be able test this hypothesis by unchecking the "Automatically adjust clock for daylight saving changes" checkbox in the "Time Zone" tab of the "Date and Time Properties" dialog that pops up when you double-click the current time string displayed at the right edge of your system tray. (You will need to reboot the machine after unchecking that option, so that Windows doesn't reuse the cached values of DST offset, when it reports UTC file times.)