Re: vc-cvs-parse-entry

[martin rudalics]

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

> 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.  I'm reluctant to change DST settings in
the registry.  (Un-)checking that box from the system tray affects the
behavior of my machine only when DST actually changes.  Changing the
time-zone settings of my machine won't affect filetimes and how they are
displayed (it might affect cvs update, though).

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.  It's sufficient to maintain a set of rules that determine whether
a modification time has to be evaluated with DST on or off.  In my
present time-zone the respective dates are the last sundays in March and
October of a year.  Getting the correct modification time of a file must
be done by adding one hour to the modification time stored on disk
provided that time falls somewhere between these dates for the year in
question.  Obviously, for one hour each year, a file B I modified after
a file A will get an earlier modification time than A.  Since I don't
work at that time I never noticed that problem.

Clearly, the "storing local times only" philospohy must fail when I move
my machine from one time-zone to another: 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.

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

On my system `file-attributes' represent local time.

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

I suppose they changed that for XP and simply forgot about FAT Windows.
In fact, installing the latest GnuWin32 also broke something in building
Emacs on my machine (probably due to a change in cp.exe).  It took me
some time to restore my fragile balance of mingw, cygwin, unxutils and
gnuwin32 tools after that.