>>>>You're welcome. One note about saying stores milliseconds. Actually not storing it as milliseconds but it's a real number keeping time as a fraction (terminology differs but result is same technically).
>>>>Cetin
>>>
>>>As a mather of fact, it IS stored in a millisecond format in the DBF. When it is used in memory it is in an floating-point format, giving rise to some rounding artifacts.
>>>
>>>(for the complete specs of how it is written to disk see my message in the newsgroup microsoft.public.fox.vfp.dbc on 22 jun 2003)
>>
>>On dbf:
>>

>>* someDatatetime
>>BINTOC(VAL(SYS(11,someDatatetime)),"RS"),BINTOC(Daymsec(someDatatetime),"RS")
>>

>>
>>On memory:
>>

>>floatvalue=VAL(SYS(11,someDatatetime))+DaySec/86400
>>

>>The problems are born because 1/86400 cannot be represented in base2.
>>
>>Only datetimes with DaySec=k*675 they are exactly stored on memory.
>
>Yes, I never understood the reasoning behind it to store milliseconds. In memory it could be:
>floatvalue=VAL(SYS(11,someDatatetime))+DaySec
>and there would be still space for a wider range of datetimes.

Cetin,

Actually, VFP rounds values to the nearest second and doesn't save the original values.

As I learned with my dealings with SQL Server over the past two days, there are some limitations with even its comparisons.

From what I can see, SQL Server 2000, has a resolution of +/- 2 milliseconds. If the difference is less than that, it treats them as if they were equal.

I assumed that because VFP stored datetimes in 8 bytes that it would correspond to either the SYSTEMTIME or FILETIME structures of Windows. Even those structure, which are both made up of 8 8 byte integers, don't take the resolution below one millisecond.