Re: vc-cvs-parse-entry

[Eli Zaretskii]

> Date: Mon, 11 Sep 2006 11:41:21 +0200
> From: martin rudalics <address@hidden>
> CC:  address@hidden
> 
> My ~/src/CVS/Entries contains the following lines:
> 
> /acldef.h/1.2/Mon Sep  1 15:45:52 2003//
> /alloca.c/1.29/Fri Jan 30 17:10:02 2004//
> /chpdef.h/1.2/Mon Sep  1 15:45:52 2003//
> /hftctl.c/1.13/Mon Sep  1 15:45:52 2003//
> /ioctl.h/1.2/Mon Sep  1 15:45:54 2003//
> /ndir.h/1.4/Mon Sep  1 15:45:56 2003//
> /param.h/1.2/Mon Sep  1 15:45:56 2003//
> /point.h/1.2/Mon Sep  1 15:45:56 2003//
> /pre-crt0.c/1.2/Mon Sep  1 15:45:56 2003//
> /stamp-h.in/1.1/Mon Apr 15 13:14:46 2002//
> /temacs.opt/1.1/Fri Oct  1 11:44:30 1999//
> /unexhp9k800.c/1.10/Mon Sep  1 15:45:58 2003//
> /vlimit.h/1.2/Mon Sep  1 15:45:58 2003//
> 
> I did "cvs co" on March 24, 2005.  I did not count the "cvs up" I did
> since then, the last one was a week ago.  Can you explain how dates in
> the range from 1999 till 2004 made it to my Entries?  IMHO, these dates
> must reflect the corresponding dates in the repository.

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.

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

>  >>On my system `file-attributes' represent local time.
>  >
>  >
>  > Really?  Can you show me why you think so?
>  >
>  > AFAICS, file-attributes returns the times it gets from `stat', and
>  > `stat' (we use a replacement in w32.c) simply calls FindFirstFile.
>  > Now, this URL in the Microsoft docs:
>  >
>  >   
> http://msdn.microsoft.com/library/default.asp?url=/library/en-us/sysinfo/base/file_times.asp
>  >
>  > says that FindFirstFile (and other similar system calls) return file
>  > times in UTC, even on FAT filesystems.
> 
> It says:
> 
> "The FAT file system stores time values based on the local time of the
> computer. For example, a file that is saved at 3:00pm PST in Washington
> is seen as 6:00pm EST in New York on an NTFS volume, but it is seen as
> 3:00pm EST in New York on a FAT volume."
> 
> Please observe the use of the terms "stores" and "seen".  It's what I
> tried to explain above: I set my computer's time-zone to PST, save a
> file at 3:00 PST according to my computer's clock, set my computer's
> time-zone to EST, the filetime shows 3:00 EST.

What program(s) did you use to show the time?  I was only talking
about what FindFirstFile returns.  To see that, you need to display
the time values returned by FindFirstFile; if you use some other
program to interpret those values, you risk inaccuracies due to
conversions made by that other program.

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

> "FindFirstFile retrieves the local time from the FAT file system and
> converts it to UTC by using the current settings for the time zone and
> daylight saving time. Therefore, if it is daylight saving time,
> FindFirstFile takes daylight saving time into account, even if the file
> time you are converting is in standard time."
> 
> Please observe the use of the term "current settings" here.  That's
> precisely the problem I experience now: Today, "it is daylight saving
> time" and the problematic files are "in standard time".

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?

> "GetFileTime retrieves cached UTC times from the FAT file system."
> 
> AFAICT, this means that FAT based Windows' cache the results of the
> calculations I described above.  Hence, using GetFileTime might solve
> the problem for FAT provided I invalidate the cache after each DST
> change.

Again, you are talking about the DST, while I was talking about the
time-zone offset, even when there's no DST factor.  I agree that the
DST rules are applied incorrectly on Windows.