Level Extreme platform
Subscription
Corporate profile
Products & Services
Support
Legal
Français
Adir(),ftime() time warp
Message
General information
Forum:
Visual FoxPro
Category:
Coding, syntax & commands
Miscellaneous
Thread ID:
00600846
Message ID:
00600999
Views:
25
Hi George,

Thanks for taking time to look at this. Very interesting.

>Sorry, I slightly misunderstood the situation. Unfortunately, I haven't been able to replicate this behavior testing on two different files on a Win2K Pro SP2 box under VFP 7.0. In both cases, under several different methods, I always got back the same results. The methods that I used to retrieve the individual file date/time stamps where:
>
>1. ADIR()
>2. FDATE() and FTIME()
>3. Retrieving a file object reference with Windows Script Host's Scripting.FileSystemObject and checking its DateLastModified member.
>4. Retrieving the results returned in a FindFirstFile() API call, and converting the last write date/time member from the WIN32_FIND_DATA structure.
>5. Retrieving the result using the GetFileTime() API call.
>
>Do you find this behavior on all files? What version of VFP are you using?
I'm using Visual FoxPro 07.00.0000.9262 for Windows and see the same results under XPpro and W2Kpro SP2.

I added WSH to my test code and still get the same result. It's definitely more than a rounding/truncation issue. Here is an example:

adir and ftime report 12:08:38
GetFileTime reports 12:08:36.503
WSH.fso reports 12:08:36

Pictures can help. I ran my repro code in a loop and recorded the seconds reported by vfp,api and wsh calls respectively. See: http://www.cornerstonenorthwest.com/fileattribs.gif

From this it looks as if x=seconds reported by getFileTime() then seconds reported by adir and ftime is always ceiling(x) + mod(ceiling(x),2) that is, always returns the next highest even integer) while wsh reports floor(x). Thus, the only place they all agree is when the seconds is and even integer.

You say you don't see this behaviour on your machine? I wonder what the difference is?

-lc
-lc
Previous
Next
Reply
Map
View

Click here to load this message in the networking platform