[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: vc-cvs-parse-entry

From: martin rudalics
Subject: Re: vc-cvs-parse-entry
Date: Sun, 03 Sep 2006 12:40:11 +0200
User-agent: Mozilla Thunderbird 1.0 (Windows/20041206)

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


and there


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


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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]