Re: vc-cvs-parse-entry

[martin rudalics]

> Then read "cvs co" instead of "cvs up".  The point here is that the
> files get their file stamps when you check them out or update them;
> the timestamp has nothing to do with when the file was last checked
> into the repository.  And the timestamps in CVS/Entries are just those
> checkout/update times in UTC (or that's what the CVS client expects to
> find there).

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.

>>Changing the time-zone settings of my machine won't affect filetimes
>>and how they are displayed
>
>
> According to the Microsoft docs, it will affect what system calls like
> FindFirstFile return.  And since `stat' calls FindFirstFile, that
> could very well explain what happens with CVS.  See below.

But it does not.  Changing time-zone settings doesn't change anything
for filetimes reported by the programs I use.  The URL

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.

This, of course, includes the case where (as in <"An example of the
problem">) a file is created in one DST season and is then read from the
opposite DST season (for example, create a file in summer (which
effectively sets a summer file time from summer) and then read it from
winter), but it also includes hitherto unseen cases in which
FindFirstFile() will even return the wrong time for a file time in the
same DST season as the current system time if the file time was set from
the opposite DST season to the current system time (for example, set a
summer file time from winter and then read it from summer). Also note
that, in other thus-far unseen cases, FindFirstFile() can return the
correct time for a file time in the opposite DST season to the current
system time if the file time was set from the same DST season as the
current system time (for example, set a winter file time from summer and
then read it from summer).

Thus, we appear to be concerned with when the file time was set relative
to the current system time, rather than what the file time is relative
to the current system time."

>>Note: For a computer that never moves from one time-zone to another it's
>>insignificant whether modification times are stored as UTC or local
>>time.
>
>
> I think it _is_ significant, since various system calls need to return
> UTC times.  On NTFS, they simply return what they find on disk, while
> on FAT, they need to decide how many hours to add/subtract to get UTC
> from the stored local times.  And that's where the problem happens:
> the offset used is the _current_ one, not the one that was in effect
> when the file was actually last written to.

Indeed - that's why I said it's insignificant how values are _stored_.
I fully agree with the remainder of what you say here.

> Sorry for repeating this, I thought we already understood the reasons
> behind this problem.  But your assertion above tells me that perhaps
> we still aren't clear about what happens.

I think we are.  You probably misunderstood my text.

>>It's sufficient to maintain a set of rules that determine whether
>>a modification time has to be evaluated with DST on or off.
>
>
> It is only sufficient if those rules are actually _applied_ when
> FindFirstFile and friends convert file times recorded by FAT to UTC.
> According to what I read in the MS docs, they don't use those rules;
> instead, they use the current offset, which could be different from
> the correct one if the DST settings then and now are different.

Whoever "they" are.  FindFirstFile does not apply these rules.

>>Clearly, the "storing local times only" philospohy must fail when I move
>>my machine from one time-zone to another
>
>
> Sending files to the CVS server _is_ moving them to a different time
> zone.

I talked about moving my _machine_.

Moving a file is conceptually simple: Moving a file to my machine means
take its time measured in UTC, convert it to the value appropriate for
my local time-zone, and save it with that value.  Moving a file from my
machine to another one means calculate the UTC value from the filetime
and the time-zone of my machine.

>>I cannot distinguish files
>>created in different time-zones since I have no notion of UTC.  Every
>>interpretation of a filetime occurs as if the file had been modified in
>>my present (virtual) time-zone.
>
>
> Sorry, I cannot figure out what you are saying here.

Time-zones are a "virtual" concept.  I can tell my computer to live in
an arbitrary time-zone, disregarding its physical location in the world.
This won't change the stored filetime of any file on my disk.  It will,
however, affect the value calculated by CVS and subsequently stored "as
filetime" on disk when I move a file from somewhere else to my machine.

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

It further says:

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

It finally says:

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

The URL I mentioned above claims that GetFileInformationByHandle
delivers correct filetimes even when DST changes in between.

> Which to me makes perfect
> sense, since `stat' on Posix systems returns UTC time stamps.

Apparently, it doesn't make sense for FAT.  I still wonder what the 3.16
Windows port of ls used instead, I never had the sources for that.