Re: vc-cvs-parse-entry

[Eli Zaretskii]

> Date: Sun, 03 Sep 2006 12:40:11 +0200
> From: martin rudalics <address@hidden>
> CC:  address@hidden
> 
>  > 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

This one partly describes what the MSDN article whose URL I posted
describes, and partly is simply wrong.  There _is_ a way of correctly
accounting for DST on NTFS, and the MSDN article says how to do that.
Presumably, library functions on Windows do that already, although I
didn't have time to check.

> and there
> 
> http://www.devguy.com/fp/cfgmgmt/cvs/

This seems to say that WinCVS figured out how to code around the
problem for FAT, but not for NTFS.

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

The latter.

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

Note that I changed to GMT+0 _and_ disabled automatic DST correction.
Thus, no additional registry changes are necessary, at least not on
XP.

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

GMT+0/no DST means the DST rules have no effect.

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

Because you are on a FAT volume.

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

Local time changes automatically on XP when you change the time zone
(my PC synchronizes with a time server via NTP, if that matters).

> My ls.exe (version 3.16 of GNU fileutils) doesn't report full time for
> files modified before March, 9th, 2006 - for whatever reason.

That's the standard ls ``6 months is way in the past'' policy.  It
only displays full time for files modified ``recently''.

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

I think file-attributes returns UTC times, since it calls `stat'.

> But do ls.exe and DIR give the same information for src/unexelf.c on
> your system?

I thought I explained that DIR reports it with a 1-hour error, due to
incorrect accounting for DST.

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

I will try when I have time, but I doubt it will be marked modified.

>  >    http://www.digital-detective.co.uk/freetools/decode.asp
> 
> What values do you paste there?  Where do you get them from?

It accepts values from `stat' or similar API functions.