Re: vc-cvs-parse-entry

[martin rudalics <rudalics@gmx.at>]

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