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: Fri, 15 Sep 2006 20:43:43 +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> <45091564.4050508@gmx.at> Reply-To: Eli Zaretskii NNTP-Posting-Host: main.gmane.org X-Trace: sea.gmane.org 1158342237 2898 80.91.229.2 (15 Sep 2006 17:43:57 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Fri, 15 Sep 2006 17:43:57 +0000 (UTC) Cc: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Sep 15 19:43:54 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 1GOHjF-0004ea-Ls for ged-emacs-devel@m.gmane.org; Fri, 15 Sep 2006 19:43:54 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1GOHjE-0002IU-Mq for ged-emacs-devel@m.gmane.org; Fri, 15 Sep 2006 13:43:52 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1GOHj4-0002IP-86 for emacs-devel@gnu.org; Fri, 15 Sep 2006 13:43:42 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1GOHj2-0002Hv-J2 for emacs-devel@gnu.org; Fri, 15 Sep 2006 13:43:41 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1GOHj2-0002Hs-Dc for emacs-devel@gnu.org; Fri, 15 Sep 2006 13:43:40 -0400 Original-Received: from [192.114.186.20] (helo=nitzan.inter.net.il) by monty-python.gnu.org with esmtp (Exim 4.52) id 1GOHlE-0005Li-80 for emacs-devel@gnu.org; Fri, 15 Sep 2006 13:45:57 -0400 Original-Received: from HOME-C4E4A596F7 (IGLD-80-230-32-7.inter.net.il [80.230.32.7]) by nitzan.inter.net.il (MOS 3.7.3-GA) with ESMTP id EQQ89634 (AUTH halo1); Fri, 15 Sep 2006 20:43:36 +0300 (IDT) Original-To: martin rudalics In-reply-to: <45091564.4050508@gmx.at> (message from martin rudalics on Thu, 14 Sep 2006 10:40:04 +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:59888 Archived-At: > Date: Thu, 14 Sep 2006 10:40:04 +0200 > From: martin rudalics > CC: emacs-devel@gnu.org > > > 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. > > Yes, but my problem isn't with time-zones. It's with DST just as > described there. Understood and agreed. However, this confusion started when you claimed that FindFirstFile did not return UTC times, but local times. I hope now we agree that it does return UTC times, except that those times are sometimes off by one hour due to the incorrect DST correction. > > 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? > > You earlier said that `stat' runs FindFirstFile. Without options stat > (version 5.3.0) gives for my standard time-zone settings (CEST): I meant the _function_ `stat' as implemented in Emacs's w32.c. I did not mean the _program_ `stat' that is part of Coreutils. If you can step with a debugger through the function `stat' in w32.c and see what times it returns for your files, it'd be great. > Can you tell something from that? Not really. It's quite obvious that `stat' the program converts the times to local time for display (witness the +0200 etc. time-zone offsets it shows). I need to see the raw times returned by the FindFirstFile API. Anyway, I'm not sure anymore whether we should pursue this issue any further, especially since Stefan thinks we shouldn't try fixing this.