Re: vc-cvs-parse-entry

[Eli Zaretskii]

> Date: Sat, 02 Sep 2006 15:45:42 +0200
> From: martin rudalics <address@hidden>
> CC:  address@hidden,  address@hidden
> 
>  >>Note that if more recent versions of w32 fixed this problem, it should be
>  >>fixed for both CVS and vc-cvs.el (and pcl-cvs ;-).
>  >
>  >
>  > Only if the CVS client uses the right code to get the file times; see
>  > the above URL for the gory details.
> 
> FWIW, CVS did "use the right code to get the file times".

By ``CVS'', do you mean ``the recently installed wincvs'' you
mentioned?  I use some old port of CVS, and it does have problems when
DST changes, even though I have an XP machine and an NTFS filesystem.
So I think the CVS port does have a say here, not only the filesystem.

> In fact. I've not been able to reproduce the modification times
> reported by (X)Emacs with any other application on my system.

Please show an example of these modification times, and how did you
compare that with whatever other applications on your system report
file times.

> Provided DST is on in your current time zone: Do you have a file on your
> system with a modification date while DST was off?

Yes, of course.  How about src/unexelf.c, for example?  It has the
modification time of March 18, 2006, 5:32PM on my system.

> Does your OS give the same modification time as Emacs?

The problem is with the ``OS'' part--how did you know what ``the OS''
thinks about that file's times?  What utilities/system calls and/or
Emacs functions you used to find that out?  I don't think we can have
any progress until we have answers for these questions, and understand
well what code is involved in reporting time stamps.  One problem is
that, for commands like DIR, we don't have any way of knowing what
they do, since their source code is not available.

What I did was to reset the time zone to GMT and disable the automatic
DST corrections, then look at what DIR (from cmd.exe) reports.  I then
set the time zone back to the normal setting, and looked at what DIR
displayed now.  My conclusion was that DIR lies about file times: it
reports them as if DST were in effect, even if the file was modified
when DST was off.  By contrast, the GnuWin32 port of ls.exe reported
the file times correctly, both for files modified under DST and files
modified outside DST.

We could make a similar check with Emacs primitives instead of ls.exe
and DIR, if needed.

But the trick with setting TZ to GMT probably won't work on FAT
volumes, since the file times are recorded as local time there.

Btw, I find the Date/Time decoder utility very useful when testing
these issues, see:

   http://www.digital-detective.co.uk/freetools/decode.asp

> It doesn't for me.  Reading the URL you suggested I think it's due
> to the following:
> 
> FindFirstFile retrieves the local time from the FAT file system and
> converts it to UTC by using the current settings for the time zone and
> daylight saving time. Therefore, if it is daylight saving time,
> FindFirstFile takes daylight saving time into account, even if the file
> time you are converting is in standard time.

It's possible.  You might be able test this hypothesis by unchecking
the "Automatically adjust clock for daylight saving changes" checkbox
in the "Time Zone" tab of the "Date and Time Properties" dialog that
pops up when you double-click the current time string displayed at the
right edge of your system tray.  (You will need to reboot the machine
after unchecking that option, so that Windows doesn't reuse the cached
values of DST offset, when it reports UTC file times.)