Hi Cetin,

It looks like the failure occours after the fourth precision as in this example

? (ltTime2 - ltTime1) * 1
? (ltTime2 - ltTime1) * 1.0
? (ltTime2 - ltTime1) * 1.00
? (ltTime2 - ltTime1) * 1.000
? (ltTime2 - ltTime1) * 1.0000
? (ltTime2 - ltTime1) * 1.00000
<\pre>

you will get a result of

3600
3600.0
3600.00
3600.000
3600.0000
3599.99999
<\pre>

>>>Unlike dates, datetime is stored as a double. I hit this sometime ago too and discussed here. If hour portion is not a multiple of 3 then roundation problems occur.
>>
>>From my understanding, it's not strictly a double, it's actually 2 integers. DateTime is stored in 8 bytes, the first 4 bytes are in integer date, offset from 1/1/100, the remaining 4 bytes are the time in milliseconds since midnight (If I'm wrong, I know I'll be shot down in flames, regardless of how close to Christmas & the season of goodwill, I'm quoting from VfP 5 help here, which has exactly the same problem).
>>
>>If this is the case, then any difference cannot really be explained as rounding error. And even if rounding error, why a difference of multiples of exactly 3 hours (180000 mS) should have no rounding error.
>>
>>Paul
>
>
Yes Paul you're right that it's not strictly a double, 2 integers. How datetime math is the problem IMHO. There should be a conversion to double.
>Try this :
>
>ltTime1 = {1/1/1999 00:00:00}
>ltTime2 = {1/1/1999 01:00:00}
>ltTime3 = {1/1/1999 02:00:00}
>ltTime4 = {1/1/1999 03:00:00}
>ltTime5 = {1/1/1999 04:00:00}
>ltTime6 = {1/1/1999 05:00:00}
>ltTime7 = {1/1/1999 06:00:00}
>ltTime8 = {1/1/1999 07:00:00}
>
>? (ltTime2 - ltTime1) * 1.0000000000
>? (ltTime3 - ltTime1) * 1.0000000000
>? (ltTime4 - ltTime1) * 1.0000000000
>? (ltTime5 - ltTime1) * 1.0000000000
>? (ltTime6 - ltTime1) * 1.0000000000
>? (ltTime7 - ltTime1) * 1.0000000000
>? (ltTime8 - ltTime1) * 1.0000000000
>
>Cetin