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, 11 Sep 2006 00:17:57 +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> Reply-To: Eli Zaretskii NNTP-Posting-Host: main.gmane.org X-Trace: sea.gmane.org 1157923105 25827 80.91.229.2 (10 Sep 2006 21:18:25 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Sun, 10 Sep 2006 21:18:25 +0000 (UTC) Cc: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Sep 10 23:18:21 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 1GMWgw-0007Su-W8 for ged-emacs-devel@m.gmane.org; Sun, 10 Sep 2006 23:18:15 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1GMWgw-00044l-9P for ged-emacs-devel@m.gmane.org; Sun, 10 Sep 2006 17:18:14 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1GMWgj-00044g-OV for emacs-devel@gnu.org; Sun, 10 Sep 2006 17:18:01 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1GMWgg-00044R-T2 for emacs-devel@gnu.org; Sun, 10 Sep 2006 17:18:00 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1GMWgg-00044O-OH for emacs-devel@gnu.org; Sun, 10 Sep 2006 17:17:58 -0400 Original-Received: from [192.114.186.66] (helo=romy.inter.net.il) by monty-python.gnu.org with esmtp (Exim 4.52) id 1GMWhn-0001EB-VV for emacs-devel@gnu.org; Sun, 10 Sep 2006 17:19:08 -0400 Original-Received: from HOME-C4E4A596F7 (IGLD-84-228-243-184.inter.net.il [84.228.243.184]) by romy.inter.net.il (MOS 3.7.3-GA) with ESMTP id FSH58392 (AUTH halo1); Mon, 11 Sep 2006 00:17:56 +0300 (IDT) Original-To: martin rudalics In-reply-to: <4503E115.4020206@gmx.at> (message from martin rudalics on Sun, 10 Sep 2006 11:55:33 +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:59640 Archived-At: > Date: Sun, 10 Sep 2006 11:55:33 +0200 > From: martin rudalics > CC: emacs-devel@gnu.org > > > 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". > > The two files in question were never affected by a cvs update after I > checked that out in early 2005. Then read "cvs co" instead of "cvs up". The point here is that the files get their file stamps when you check them out or update them; the timestamp has nothing to do with when the file was last checked into the repository. And the timestamps in CVS/Entries are just those checkout/update times in UTC (or that's what the CVS client expects to find there). > Earlier you wrote: > > > How about src/unexelf.c, for example? It has the > > modification time of March 18, 2006, 5:32PM on my system. > > According to your reasoning above wouldn't this imply you never did a > cvs update after March 2006? Yes, see above. > > 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? > > I wouldn't know what to reset. The date in your machine's BIOS. > I'm reluctant to change DST settings in the registry. I cannot imagine why (since you'd be restoring it to its original value right after that), but it's your machine. Unfortunately, if I don't have someone with access to a Windows 9x system who can work with me on this, the problem, if there is one, will not be solved any time soon. > Changing the time-zone settings of my machine won't affect filetimes > and how they are displayed According to the Microsoft docs, it will affect what system calls like FindFirstFile return. And since `stat' calls FindFirstFile, that could very well explain what happens with CVS. See below. > Note: For a computer that never moves from one time-zone to another it's > insignificant whether modification times are stored as UTC or local > time. I think it _is_ significant, since various system calls need to return UTC times. On NTFS, they simply return what they find on disk, while on FAT, they need to decide how many hours to add/subtract to get UTC from the stored local times. And that's where the problem happens: the offset used is the _current_ one, not the one that was in effect when the file was actually last written to. Sorry for repeating this, I thought we already understood the reasons behind this problem. But your assertion above tells me that perhaps we still aren't clear about what happens. > It's sufficient to maintain a set of rules that determine whether > a modification time has to be evaluated with DST on or off. It is only sufficient if those rules are actually _applied_ when FindFirstFile and friends convert file times recorded by FAT to UTC. According to what I read in the MS docs, they don't use those rules; instead, they use the current offset, which could be different from the correct one if the DST settings then and now are different. > Clearly, the "storing local times only" philospohy must fail when I move > my machine from one time-zone to another Sending files to the CVS server _is_ moving them to a different time zone. > I cannot distinguish files > created in different time-zones since I have no notion of UTC. Every > interpretation of a filetime occurs as if the file had been modified in > my present (virtual) time-zone. Sorry, I cannot figure out what you are saying here. > 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. Which to me makes perfect sense, since `stat' on Posix systems returns UTC time stamps. If you see something else, please tell me where in the Emacs code that is involved in file-attributes you see the file times returned in local time or converted to local time. TIA