>Hi All,
>
>I've noticed that the last modified times reported by adir() and ftime() seem to be about 1-2 seconds ahead of what datetime() will report just after the file is written or what the API function GetFileTime() reports for the file.
>
>It's odd because it's more than a round off error; sometimes it is more than 1 second off each time. This seems like a bug to me. Also, due to the rounding done (only seconds are reported) it would be impossible to apply an adjustment to the results to obtain accurate times from adir() or ftime().

Lauren and George,

I didn't dive into th problem like you both did, but maybe here's a suggestion :

I'm not this technie, but a sort of similar puzzled me for a few years now and I could never find the real solution, though I have an idea about it;
Suppose you run your whatever OS-PC on a Novell system, with a Citrix server involved. For our litteral situation this means that a file is mofified on the PC, but the file is on the Novell server, in fact saving it (to the network's disk). The time of your PC is synchronized with the server (all PC's OSses allow for that), and the first thing you can wonder is whether the time of the file is from the PC or from Novell (just never tested this). But, somewhere in the back the Citrix is running, and in our situation it is re-generating the code just saved, and the Citrix task (running as a background job) saves the file again. Now I'm 100 % sure things are somehow strange in there (or in this combination of things), and the time Citrix implies will be different from Novell / PC. Now ususally this can't be noticed i.e. when all is right there is no problem. BTW, Citrix is synchronized with Novell as well.

The problem occurs when the Novell server occasionally stops increasing the time, due to some (as we expect) CD-Rom problem in the server, and Novell's time start to run late; the PC's do as well (because synchronized but at login only), and we are having problems with VFP finding the proper version of the file. Sidenote : more versions of the file will exist, thinking of FXP vs. PRG etc.).

Now the above is not some mentioning of a problem, but I wanted to say that there are more sources to the time of a file, and mainly Lauren could examine whether this is his problem. I mean, when George hasn't the problem, it may be -or should be Lauren's environment.

Where the above seems not related at all, I also want to emphasize the strangenes we have with some of our customers, and the sending of a file created by us at 09:00 will be after the sending over PCAnywhere 10:00 at the customers site. So, this will be the resolution of NTFS ? I wonder.
What I, however, do expect, is that all runs over the timezone system, and in there something might be wrong or strange; The PCAnywhere problem surely has nothing to do with times differing one hour, and they are just the same. The one hour difference at the according customers is not "now and then" but always.

So maybe timezone settings are relative to something, and don't work out properly ? And it can be at the seconds level ?

Last thing :
Last year I had this small loop, showing Seconds() as fast as it could. In FPD a next line could show an earlier time than a before line. Did you guess that ? I couldn't reproduce this in VFP, but that may be because of other reasons.


So, sorry that I jumped in, but maybe it helps ...