>>run this some time ... and you get a random time glitch
>>

>>CLEAR
>>FOR k=1 TO 1000000
>>	IF INT(SECONDS())#DATETIME()-DTOT(DATE()) && This should always be true
>>		? SECONDS(),DATETIME(),DATETIME()-DTOT(DATE())
>>	ENDIF
>>NEXT
>>

>
>Ran it ten times, found none. Maybe I finally have a machine that's fast enough?

I think that's exactly it. If you run my code

ltStart = DATETIME( ) + MOD( SECONDS( ), 1 )

at exactly the wrong time e.g. suppose the DATETIME( ) portion is run at some ( real ) time when the seconds portion is 0.999 seconds. DATETIME( ) will return 0 as the seconds portion.

Then, some short time period later, VFP processes the SECONDS( ) call. If that call is only 1 msec later, it will return its millisecond fraction as .000. So the combined result would be 0.000, when it should be 0.999. Come to think of it, if a machine is busy and VFP gets pre-empted then the time window between the two calls could get much larger. If the real-time second boundary falls anywhere in that window problems will crop up.

Your machine is fast enough ( and not busy enough ) that the problem window is very small. The tests you ran didn't hit any initial times close enough to a second boundary for the problem to show up.

>Tried this too:
>

STORE datetime() to x,y
>x = x + 0.323
>?x=y

?x-y  && 0
? 0.000 + ( x - y )  && 0.323
>

>
>It seems the datetime values don't hold milliseconds anymore.

The milliseconds are still there, but well hidden. It looks like standard ( integer ) arithmetic and function calls like DATETIME( ) are treating them as integer seconds, which makes life easier for those doing equality comparisons, SEEKs in tables etc. Switching to real arithmetic unlocks the milliseconds.