Hi George,
I can confirm the "bugs", I tried it with VFP 5.0a on Win98SE, and VFP 6.0 SP3 on NTW 4.0 SP5. In fact, I had observed this before and created a wrapper function (w/ the timezone bias and added the missing parameters) to give a function that works just like the FPW version, for a program that had been "converted".

Rick

---

>>Erik,
>>One thing that hasn't been mentioned is that VFP 5/6 FoxTouch() function works just slightly different than the FPW version. The date and time you provide is "adjusted" by your timezone offset before it's applied to the file. So you either have to know what this TZ bias is, OR read it from the registry. Of course it's stored in a binary value so you can't use the standard REGISTRY.PRG.
>>
>Hi Rick,
>
>I don't know about VFP 5.0 (don't have access any longer), but I just attempted to verify this, and you're right. I also seem to have come across a bug or two in the function. Though I can't confirm, I'll mention that last.
>
>I would guess that the reason for this has something to do with the way 32 bit Windows stores file times. They're stored in UTC format. I'd surmise that what's happening is that the values that are passed, are stored in a SYSTEMTIME structure. In order to convert that to a FILETIME structure, the function SystemTimeToFileTime() in the API should be called. The contents of this structure, however, is still local representation of the time. In order for it to be properly set, the function LocalFileTimeToFileTime() should be called to adjust the time. Apparently this step is being omitted and would account for th problem.
>
>Onto other bugs. The first time I attempted to call the function, I got a data type mismatch when I only passed the file name. According to both my docs and MS's this should result in the current Date/Time being used. This behavior stopped (the data type mismatch) after I called the function will the full parameter list (year, month, day, etc.). It would then accept the paramter. One problem...it didn't do anything.
>
>Would someone kindly confirm this for me?
>
>Note to Rick,
>
>You don't have to use the registry to get the bias between your current timezone and UTC time. You can call, GetTimeZoneInformation() to retrieve this and other values.