Re: YANFCQ [Yet Another Non-FastCode Question]: TDateTime -> uSec resolution
- From: Lord Crc <lordcrc@xxxxxxxxxxx>
- Date: Thu, 28 Jul 2005 13:44:51 +0200
On Thu, 28 Jul 2005 11:42:18 +0200, "Kristofer Skaug"
<nospam@xxxxxxxxx> wrote:
>For example if you set up the
>TDateTime input as a pure Time (no date component) then precision is much
>better than if you start with a combined Date+Time value; in this case
>Frac(ATime) gets dangerously close to hacking off half-microseconds or more.
Yes, TDateTime isn't really meant for that kind of precision. Can't
you use an all-out integer approach?
- Asbjørn
.
- Follow-Ups:
- Re: YANFCQ [Yet Another Non-FastCode Question]: TDateTime -> uSec resolution
- From: Kristofer Skaug
- Re: YANFCQ [Yet Another Non-FastCode Question]: TDateTime -> uSec resolution
- References:
- YANFCQ [Yet Another Non-FastCode Question]: TDateTime -> uSec resolution
- From: Kristofer Skaug
- Re: YANFCQ [Yet Another Non-FastCode Question]: TDateTime -> uSec resolution
- From: Lord Crc
- Re: YANFCQ [Yet Another Non-FastCode Question]: TDateTime -> uSec resolution
- From: Kristofer Skaug
- YANFCQ [Yet Another Non-FastCode Question]: TDateTime -> uSec resolution
- Prev by Date: Re: Fastcode MM B&V 0.47
- Next by Date: Re: Fastcode MM B&V 0.47
- Previous by thread: Re: YANFCQ [Yet Another Non-FastCode Question]: TDateTime -> uSec resolution
- Next by thread: Re: YANFCQ [Yet Another Non-FastCode Question]: TDateTime -> uSec resolution
- Index(es):