Re: vc-cvs-parse-entry

[martin rudalics]

> Maybe, I don't know anymore.  I have 2 checkouts of the Emacs tree on
> my system, one has the same times as you show above (well, almost:
> acldef.h has the time stamp of 15:45:51, not 15:45:52, which is also
> weird), while the other checkout has a very different time, which
> seems to be the time I checked out the tree.

I'm afraid you don't have a backup of the files from the first checkout.
Otherwise you could have a look at their modification times.

The off by one error might have something to do with the resolution of
Windows time and/or some arithmetics around that - didn't we discuss a
similar subject before?  Anyway, it's not related to Emacs.

>>http://search.cpan.org/~shay/Win32-UTCFileTime-1.45/lib/Win32/UTCFileTime.pm
>>
>>tells me
>>
>>"... that the problem with FindFirstFile() on a FAT drive actually seems
>>to be this: the file time retrieved is wrong by one hour if it was set
>>in the opposite DST season to the current system time.
>
>
> I wasn't talking about DST, I was talking about the time-zone offset
> from UTC.  Most time zones have non-zero offset between UTC and the
> local time even when the DST is not in effect.

Yes, but my problem isn't with time-zones.  It's with DST just as
described there.

>>That's incorrect, and
>>the cause is that my filetimes are local time.  Your system should get
>>you 6:00 EST instead because your filetimes are UTC.
>
>
> I was talking about what FindFirstFile returns, not about what's
> recorded on disk.  There's no argument that NTFS records file times in
> UTC, while FAT records them in local time.  The question is: does
> FindFirstFile convert file times to UTC on FAT volumes; the MS docs
> tells quite clearly that it does.  Can you please verify that
> directly, and show the actual numbers returned by FindFirstFile on
> your system?

You earlier said that `stat' runs FindFirstFile.  Without options stat
(version 5.3.0) gives for my standard time-zone settings (CEST):

  File: `c:\\Programme\\Emacs\\src\\acldef.h'
  Size: 1188            Blocks: 8          IO Block: 4096   regular file
Device: 181f1301h/404689665d    Inode: 48878265426772015  Links: 1
Access: (0666/-rw-rw-rw-)  Uid: (    0/  martin)   Gid: (    0/ UNKNOWN)
Access: 2006-09-13 00:00:00.000000000 +0200
Modify: 2003-09-01 17:45:52.000000000 +0200
Change: 2006-08-21 14:32:55.710000000 +0200

  File: `c:\\Programme\\Emacs\\src\\alloca.c'
  Size: 15285           Blocks: 32         IO Block: 4096   regular file
Device: 181f1301h/404689665d    Inode: 48878269721739315  Links: 1
Access: (0777/-rwxrwxrwx)  Uid: (    0/  martin)   Gid: (    0/ UNKNOWN)
Access: 2006-09-13 00:00:00.000000000 +0200
Modify: 2004-01-30 17:10:02.000000000 +0100
Change: 2006-08-21 14:32:55.740000000 +0200

and tersely

c:\Programme\Emacs\src\acldef.h 1188 8 81b6 0 0 181f1301 48878265426772015 1 0 
0 1158098400 1062431152 1156163575 4096
c:\Programme\Emacs\src\alloca.c 15285 32 81ff 0 0 181f1301 48878269721739315 1 
0 0 1158098400 1075479002 1156163575 4096

Changing my time-zone to GMT (_without_ changing the DST setttings) gets
me:

  File: `c:\\Programme\\Emacs\\src\\acldef.h'
  Size: 1188            Blocks: 8          IO Block: 4096   regular file
Device: 181f1301h/404689665d    Inode: 48878265426772015  Links: 1
Access: (0666/-rw-rw-rw-)  Uid: (    0/  martin)   Gid: (    0/ UNKNOWN)
Access: 2006-09-13 00:00:00.000000000 +0100
Modify: 2003-09-01 17:45:52.000000000 +0100
Change: 2006-08-21 14:32:55.710000000 +0100

  File: `c:\\Programme\\Emacs\\src\\alloca.c'
  Size: 15285           Blocks: 32         IO Block: 4096   regular file
Device: 181f1301h/404689665d    Inode: 48878269721739315  Links: 1
Access: (0777/-rwxrwxrwx)  Uid: (    0/  martin)   Gid: (    0/ UNKNOWN)
Access: 2006-09-13 00:00:00.000000000 +0100
Modify: 2004-01-30 17:10:02.000000000 +0000
Change: 2006-08-21 14:32:55.740000000 +0100

and tersely

c:\Programme\Emacs\src\acldef.h 1188 8 81b6 0 0 181f1301 48878265426772015 1 0 
0 1158102000 1062434752 1156167175 4096
c:\Programme\Emacs\src\alloca.c 15285 32 81ff 0 0 181f1301 48878269721739315 1 
0 0 1158102000 1075482602 1156167175 4096

Can you tell something from that?

> But even if the DST settings are applied incorrectly, FindFirstFile
> _does_ convert to UTC, according to the above quote.  For example, if
> my standard time is UTC + 0200, then FindFirstFile should subtract 2
> hours from the local times stored by the FAT filesystem, even if it
> thinks the DST is not in effect.  If it thinks that DST is in effect,
> then it should subtract 3 hours.  So there's an uncertainty between 2
> and 3 hours, but there should be NO uncertainty about the fact that
> FindFirstFile subtracts at least 2 hours in my timezone, trying to
> convert local times to UTC.  Are we in agreement about this?

Hopefully.  Looks like FindFirstFile performs some calculations that are
undone by stat afterwards.  But, honestly, I'm too silly to understand
that.  In particular, DCode when applied to the "terse" output of stat
gives results that differ from those produced by stat without options.