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, 12 Sep 2006 06:50:59 +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> <4503E115.4020206@gmx.at> <45052F41.5010501@gmx.at> Reply-To: Eli Zaretskii NNTP-Posting-Host: main.gmane.org X-Trace: sea.gmane.org 1158033079 22876 80.91.229.2 (12 Sep 2006 03:51:19 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Tue, 12 Sep 2006 03:51:19 +0000 (UTC) Cc: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Sep 12 05:51:17 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 1GMzIn-0000sy-3e for ged-emacs-devel@m.gmane.org; Tue, 12 Sep 2006 05:51:13 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1GMzIm-0004Ax-MK for ged-emacs-devel@m.gmane.org; Mon, 11 Sep 2006 23:51:12 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1GMzIb-0004Aa-BJ for emacs-devel@gnu.org; Mon, 11 Sep 2006 23:51:01 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1GMzIZ-0004AO-KB for emacs-devel@gnu.org; Mon, 11 Sep 2006 23:51:01 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1GMzIZ-0004AL-Fi for emacs-devel@gnu.org; Mon, 11 Sep 2006 23:50:59 -0400 Original-Received: from [192.114.186.73] (helo=heller.inter.net.il) by monty-python.gnu.org with esmtp (Exim 4.52) id 1GMzJy-0008VO-E4 for emacs-devel@gnu.org; Mon, 11 Sep 2006 23:52:26 -0400 Original-Received: from HOME-C4E4A596F7 (IGLD-83-130-5-189.inter.net.il [83.130.5.189]) by heller.inter.net.il (MOS 3.7.3a-GA) with ESMTP id ALC60244 (AUTH halo1); Tue, 12 Sep 2006 06:50:56 +0300 (IDT) Original-To: martin rudalics In-reply-to: <45052F41.5010501@gmx.at> (message from martin rudalics on Mon, 11 Sep 2006 11:41:21 +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:59722 Archived-At: > Date: Mon, 11 Sep 2006 11:41:21 +0200 > From: martin rudalics > CC: emacs-devel@gnu.org > > My ~/src/CVS/Entries contains the following lines: > > /acldef.h/1.2/Mon Sep 1 15:45:52 2003// > /alloca.c/1.29/Fri Jan 30 17:10:02 2004// > /chpdef.h/1.2/Mon Sep 1 15:45:52 2003// > /hftctl.c/1.13/Mon Sep 1 15:45:52 2003// > /ioctl.h/1.2/Mon Sep 1 15:45:54 2003// > /ndir.h/1.4/Mon Sep 1 15:45:56 2003// > /param.h/1.2/Mon Sep 1 15:45:56 2003// > /point.h/1.2/Mon Sep 1 15:45:56 2003// > /pre-crt0.c/1.2/Mon Sep 1 15:45:56 2003// > /stamp-h.in/1.1/Mon Apr 15 13:14:46 2002// > /temacs.opt/1.1/Fri Oct 1 11:44:30 1999// > /unexhp9k800.c/1.10/Mon Sep 1 15:45:58 2003// > /vlimit.h/1.2/Mon Sep 1 15:45:58 2003// > > I did "cvs co" on March 24, 2005. I did not count the "cvs up" I did > since then, the last one was a week ago. Can you explain how dates in > the range from 1999 till 2004 made it to my Entries? IMHO, these dates > must reflect the corresponding dates in the repository. Maybe, I don't know anymore. I have 2 checkouts of the Emacs tree on my system, one has the same times as you show above (well, almost: acldef.h has the time stamp of 15:45:51, not 15:45:52, which is also weird), while the other checkout has a very different time, which seems to be the time I checked out the tree. > http://search.cpan.org/~shay/Win32-UTCFileTime-1.45/lib/Win32/UTCFileTime.pm > > tells me > > "... that the problem with FindFirstFile() on a FAT drive actually seems > to be this: the file time retrieved is wrong by one hour if it was set > in the opposite DST season to the current system time. I wasn't talking about DST, I was talking about the time-zone offset from UTC. Most time zones have non-zero offset between UTC and the local time even when the DST is not in effect. > >>On my system `file-attributes' represent local time. > > > > > > Really? Can you show me why you think so? > > > > AFAICS, file-attributes returns the times it gets from `stat', and > > `stat' (we use a replacement in w32.c) simply calls FindFirstFile. > > Now, this URL in the Microsoft docs: > > > > http://msdn.microsoft.com/library/default.asp?url=/library/en-us/sysinfo/base/file_times.asp > > > > says that FindFirstFile (and other similar system calls) return file > > times in UTC, even on FAT filesystems. > > It says: > > "The FAT file system stores time values based on the local time of the > computer. For example, a file that is saved at 3:00pm PST in Washington > is seen as 6:00pm EST in New York on an NTFS volume, but it is seen as > 3:00pm EST in New York on a FAT volume." > > Please observe the use of the terms "stores" and "seen". It's what I > tried to explain above: I set my computer's time-zone to PST, save a > file at 3:00 PST according to my computer's clock, set my computer's > time-zone to EST, the filetime shows 3:00 EST. What program(s) did you use to show the time? I was only talking about what FindFirstFile returns. To see that, you need to display the time values returned by FindFirstFile; if you use some other program to interpret those values, you risk inaccuracies due to conversions made by that other program. > That's incorrect, and > the cause is that my filetimes are local time. Your system should get > you 6:00 EST instead because your filetimes are UTC. I was talking about what FindFirstFile returns, not about what's recorded on disk. There's no argument that NTFS records file times in UTC, while FAT records them in local time. The question is: does FindFirstFile convert file times to UTC on FAT volumes; the MS docs tells quite clearly that it does. Can you please verify that directly, and show the actual numbers returned by FindFirstFile on your system? > "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." > > Please observe the use of the term "current settings" here. That's > precisely the problem I experience now: Today, "it is daylight saving > time" and the problematic files are "in standard time". But even if the DST settings are applied incorrectly, FindFirstFile _does_ convert to UTC, according to the above quote. For example, if my standard time is UTC + 0200, then FindFirstFile should subtract 2 hours from the local times stored by the FAT filesystem, even if it thinks the DST is not in effect. If it thinks that DST is in effect, then it should subtract 3 hours. So there's an uncertainty between 2 and 3 hours, but there should be NO uncertainty about the fact that FindFirstFile subtracts at least 2 hours in my timezone, trying to convert local times to UTC. Are we in agreement about this? > "GetFileTime retrieves cached UTC times from the FAT file system." > > AFAICT, this means that FAT based Windows' cache the results of the > calculations I described above. Hence, using GetFileTime might solve > the problem for FAT provided I invalidate the cache after each DST > change. Again, you are talking about the DST, while I was talking about the time-zone offset, even when there's no DST factor. I agree that the DST rules are applied incorrectly on Windows.