Re: vc-cvs-parse-entry

[Eli Zaretskii]

> From: Stefan Monnier <address@hidden>
> Date: Tue, 29 Aug 2006 17:06:50 -0400
> Cc: address@hidden
> 
> >> What system is that (w32?)?
> > In GNU Emacs 22.0.50.1 (i386-mingw-windows98.3000)
> 
> Then it's a known problem that's pretty hard to fix:
> 
> w32 handles DST by changing the definition of "time 0"

This is not really accurate, at least on newer versions of Windows;
see below.

> so during the DST-change things behave as if all the files's
> timestamps had been changed by 1 hour.
> 
> So there really is a 1-hour difference between what the CVS/Entries file
> says and what the file's time stamp says.  We could try to be more clever
> with such situations, but since it's basically a case of braindamage in the
> w32 "spec" I'd rather not bother.

I'm not familiar with the details, nor with vc-cvs in general, so
what's below might be nonsense; sorry if so.

Is the problem you describe above in Emacs or in the CVS client that
Emacs runs?  If the latter, I agree that some (or maybe all) Windows
ports of the CVS client don't DTRT in this case.

If this is the problem, the only way to fix it is to complain to the
maintainer(s) of the CVS port and maybe provide a patch to them.

However, if the problem is in Emacs, we might be able to fix it, if
someone describes what Emacs functions are involved.  This is because
Windows does maintain the DST change rules, and its implementation of
localtime is supposed to use those rules, if they are known to the OS,
when it computes the tm_isdst member of struct tm.  So, at least in
principle, the required information is available, and can be used to
DTRT in this case.  For example, in the GnuWin32 port of Diffutils, I
see that the file times are reported with correct TZ offsets, like
this:

  --- make.h~0   2006-02-16 03:54:43.000000000 +0200
  +++ make.h     2006-08-18 21:12:32.859375000 +0300

As you see, Diff correctly determines that the old version was before
the DST change, while the new was after it.  AFAICS, Diff uses
strftime (which in turn uses localtime) to get at this information.

> IIRC "cvs update" will fix things for you.

Yes, but it's _awfully_ slow.  I needed to write a program to move the
files' last write timestamp by N hours, to avoid the resultant lossage
on Windows, whereby "cvs up" after a DST change can take _hours_
because each file is sent upstream due to the time mismatch.

Again, sorry if what I said doesn't make sense in the context of this
discussion.