Hi Andrew,

Yes, I know about the strict date format. I just think that the BRITISH date format is the best <s>.

Regards,
Gavin...

>Hi Gavin,
>
>The datetime() approach works well when the resulution required is 1 second or greater. Seconds() returns down to 100ths of a second.
>
>On a different note, remember that you can use strict date literals if your code below read
>

>dtStartTime   = {^2001-07-04 11:59:59 PM}
>dtEndTime     = {^2001-07-04 12:00:01 AM}
>nTotalSeconds = dtEndTime - dtStartTime
>

>it would work regardless of SET("DATE") - note the caret before the year.
>
>Cheers,
>
>Andrew
>
>>Hi Michel,
>>
>>SECONDS() only returns the number of seconds passed since midnight.
>>
>>Using DATETIME() should solve this problem.
>>
>>

>>dtStartTime   = {04/07/2001 11:59:59 PM}
>>dtEndTime     = {05/07/2001 12:00:01 AM}
>>nTotalSeconds = dtEndTime - dtStartTime
>>

>>
>>The above example will return 2 seconds.
>>
>>Please note that I'm using a BRITISH date format.
>>
>>Hope this helps,
>>Gavin...
>>
>>>This is a strange situation I wanted to talk about. The Universal Thread is using the Visual FoxPro Seconds() function to calculate the amount of time required to process a transaction. When the transaction is completed, we issue REPLACE LAP WITH SECONDS()-gnTime where gnTime contains the Seconds() start time. So, this is usually returning 0 to 1 second lap time as this is about what it takes to process a Universal Thread transaction.
>>>
>>>Now, tonight I faced a situation where an error was returned at that line. After a few investigations, I finally found that the transaction started in the last second of the day and ended in the first second of the new day. So, I added a condition to detect if the SECONDS() is greater than gnTime in order to avoid that. But, the weird situation is that this is unlikely to happen as it requires a lot of precision. I had it about 4 times in the first 6 months of 2001. <s>