Re: vc-cvs-parse-entry

[Eli Zaretskii]

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

Then read "cvs co" instead of "cvs up".  The point here is that the
files get their file stamps when you check them out or update them;
the timestamp has nothing to do with when the file was last checked
into the repository.  And the timestamps in CVS/Entries are just those
checkout/update times in UTC (or that's what the CVS client expects to
find there).

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

Yes, see above.

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

The date in your machine's BIOS.

> I'm reluctant to change DST settings in the registry.

I cannot imagine why (since you'd be restoring it to its original
value right after that), but it's your machine.

Unfortunately, if I don't have someone with access to a Windows 9x
system who can work with me on this, the problem, if there is one,
will not be solved any time soon.

> Changing the time-zone settings of my machine won't affect filetimes
> and how they are displayed

According to the Microsoft docs, it will affect what system calls like
FindFirstFile return.  And since `stat' calls FindFirstFile, that
could very well explain what happens with CVS.  See below.

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

I think it _is_ significant, since various system calls need to return
UTC times.  On NTFS, they simply return what they find on disk, while
on FAT, they need to decide how many hours to add/subtract to get UTC
from the stored local times.  And that's where the problem happens:
the offset used is the _current_ one, not the one that was in effect
when the file was actually last written to.

Sorry for repeating this, I thought we already understood the reasons
behind this problem.  But your assertion above tells me that perhaps
we still aren't clear about what happens.

> It's sufficient to maintain a set of rules that determine whether
> a modification time has to be evaluated with DST on or off.

It is only sufficient if those rules are actually _applied_ when
FindFirstFile and friends convert file times recorded by FAT to UTC.
According to what I read in the MS docs, they don't use those rules;
instead, they use the current offset, which could be different from
the correct one if the DST settings then and now are different.

> Clearly, the "storing local times only" philospohy must fail when I move
> my machine from one time-zone to another

Sending files to the CVS server _is_ moving them to a different time
zone.

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

Sorry, I cannot figure out what you are saying here.

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

Really?  Can you show me why you think so?

AFAICS, file-attributes returns the times it gets from `stat', and
`stat' (we use a replacement in w32.c) simply calls FindFirstFile.
Now, this URL in the Microsoft docs:

  
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/sysinfo/base/file_times.asp

says that FindFirstFile (and other similar system calls) return file
times in UTC, even on FAT filesystems.  Which to me makes perfect
sense, since `stat' on Posix systems returns UTC time stamps.

If you see something else, please tell me where in the Emacs code that
is involved in file-attributes you see the file times returned in
local time or converted to local time.

TIA