[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: vc-cvs-parse-entry

From: martin rudalics
Subject: Re: vc-cvs-parse-entry
Date: Tue, 05 Sep 2006 11:10:20 +0200
User-agent: Mozilla Thunderbird 1.0 (Windows/20041206)

> Please tell which of these results are correct.  I don't know what are
> the details of the DST rules in your locale.

I can't.  I don't know how to get the original times from the server.

There is, however, one thing I know: ediff uses

(ediff-format-date (decode-time file-modtime))

where file-modtime is taken from (nth 5 (file-attributes filename)) to
insert modification times in listings.

Now I happen to keep around backups of ediff output.  In particular I
have a file called "cus-edit.patch".  Its modification time according to
Emacs is 2006-02-26 17:29:48.  (According to DIR its 26.02.06 18:29.)
The file contains the following ediff output:

*** cus-edit.el Wed Feb  1 10:17:44 2006
--- cus-edit.el Sun Feb 26 18:11:40 2006

With the modification time reported by Emacs I must have

- saved `cus-edit.el' at 18:11:40,

- run ediff, and

- saved the output of ediff to "cus-edit.patch" at 17:29:48.

That's paradoxal.  (I verified that with a couple of other files, of

There's a second clue.  I use (add-hook 'before-save-hook 'time-stamp).
Now I have a backup of a file containing the line

;; Time-stamp: "2006-02-03 18:32:33 martin"

the modification time of that file as reported by Emacs reads as
2006-02-03 17:32:32.

Hence I strongly conjecture that when DST is on, `file-attributes'
returns the wrong modification time for files saved when DST was off for

>>BTW, stat (GNU coreutils) 5.3.0 gives the same results as Emacs, hence
>>the results delivered by stat and ls (GNU fileutils) 3.16 differ on my
> The GnuWin32 ports use a different implementation of stat nowadays,
> perhaps that's the cause for the different results.

ls (GNU coreutils) 5.3.0 does the same as stat (GNU coreutils) 5.3.0.
I conjecture that both report wrong times for Windows98/FAT32.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]