Re: vc-cvs-parse-entry

[martin rudalics]

>>FWIW, CVS did "use the right code to get the file times".
>
>
> By ``CVS'', do you mean ``the recently installed wincvs'' you
> mentioned?

No. I mean Concurrent Versions System (CVS) 1.11.19 (client).

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

Maybe it's related to what I read here

http://www.codeproject.com/datetime/dstbugs.asp

and there

http://www.devguy.com/fp/cfgmgmt/cvs/

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

It's the problem we had before, just in reverse.  I did a CVS update on
April 11th, 2006.

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

Did you change your local time in the BIOS?  Did you change the time
zone settings in

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\TimeZoneInformation\

Or did you simply check the box about automatic correction from the
system tray?  That just dis-/enables setting local time after the first
start of Windows when DST has changed by consulting

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Time Zones\

My settings for this are

C4 FF FF FF 00 00 00 00
C4 FF FF FF 00 00 0A 00  <-- 0A means "october"
00 00 05 00 03 00 00 00  <-- 05 means last sunday, 03 at three o'clock
00 00 00 00 00 00 03 00  <-- 03 means "march"
00 00 05 00 02 00 00 00  <-- 05 means last sunday, 02 at two o'clock
00 00 00 00

Did you change that?

I have checked the box on the present partition and disabled it on all
other partitions.  Otherwise I'd change my local time whenever I switch
to another partition after DST changed.  (Un-)checking the box does not
have any impact on how file modification times are reported.

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

Because you neither changed your local time nor the respective registry
settings, I presume.  (I think it's better to leave them alone, anyway.)

> By contrast, the GnuWin32 port of ls.exe reported
> the file times correctly, both for files modified under DST and files
> modified outside DST.

Because ls refers to the UTC value stored on disk.  I don't have that.

My ls.exe (version 3.16 of GNU fileutils) doesn't report full time for
files modified before March, 9th, 2006 - for whatever reason.  However,
the times reported by ls for files last modified around March 15, 2006
match those reported by DIR and other applications.  They are _not_
identic to those reported by Emacs' file-attributes.

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

But do ls.exe and DIR give the same information for src/unexelf.c on
your system?  And what would interest me most: Could you try to debug
`vc-cvs-parse-entry' while opening src/unexelf.c and look whether it
classifies the file as modified?

> Btw, I find the Date/Time decoder utility very useful when testing
> these issues, see:
>
>    http://www.digital-detective.co.uk/freetools/decode.asp

What values do you paste there?  Where do you get them from?

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

This is not sufficient as I tried to explain above.