Re: vc-cvs-parse-entry

[Eli Zaretskii]

> Date: Tue, 05 Sep 2006 11:10:20 +0200
> From: martin rudalics <address@hidden>
> CC:  address@hidden
> 
>  > 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.

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

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?

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

But you didn't compare the result of file-attributes, you compared the
result of running file-attributes' value through format-time-string,
which converts the value to local time.  We need to separate these two
unknowns, I think.

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

This comes as no surprise, since no doubt _all_ programs in the ported
Coreutils, including stat, were linked against the same implementation
of the library function `stat'.