Re: vc-cvs-parse-entry

[martin rudalics]

> 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
course.)


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
Windows98/FAT32.


>>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
>>system.
>
>
> 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.