>OK for your records it stores it with milliseconds. It seemingly doesn't provide access to it but for any queries depending on datetime value you should be prepared for that. Otherwise you get empty resulset where you expected some records to return. IOW:
>
>select * from myTable where myDatetime = m.ltTime
>
>is dangerous. Here is a simple reproducing code:
>
>

>Create cursor test (myTime t)
>For ix=0 to 23
>	Insert into test values (Datetime(2000,1,1,m.ix))
>	ltCheck = Ctot('^2000/1/1 '+Padl(m.ix,2,'0'))
>	If (m.ltCheck - test.myTime <> 0)
>	? 'Mismatch',m.ix
>	endif
>EndFor
>

This is interesting. I've known about this issue since VFP5.0, and I thought it was fixed, but it seems I was running the wrong tests. I usually tried to store datetime to a variable, and then store it into a datetime field, and see if there's a difference. This part still works - these seem to be rounded to seconds.

But running your example, even with

ltCheck=Datetime(2000,1,1,m.ix)

i.e. having the check variable assigned the same value as the one inserted into the cursor, gives me 0.0010058283810 seconds difference each time, on certain values of ix. Which is really weird. One would expect that the datetime() function would yield a round number of seconds, but it doesn't:

t=datetime()
insert into test values (t)
?(t-mytime)*1.00000000000000   && displays zero
t=ctot(ttoc(t))    && this should force it to discard milliseconds if it had them
?(t-mytime)*1.00000000000000   && displays 0.0010058283810 again

Internally, the time part of the datetime is just an 32 bit integer. So there's obviously something in the way this integer is stored into a datetime variable, that makes it behave like a badly rounded float.

Still somewhat buggy, I agree.