Re: YANFCQ [Yet Another Non-FastCode Question]: TDateTime -> uSec resolution

Lord Crc wrote:
> Yes, TDateTime isn't really meant for that kind of precision.
> Can't you use an all-out integer approach?

In the space industry there's the "CCSDS Unsegmented time Code" (CUC) as
well as "CCSDS Day-Segmented time code" (CDS) which are both strictly
integer based:

CUC: 32-bit Elapsed Seconds since <some Epoch, usually 01/01/1970>
+ 24-bit binary fraction of second
(counter 0-FFFFFF where LSbit = 1/(2^24-1) sec)

CDS: 16-bit Elapsed Days since <some Epoch>
+ 32-bit Elapsed Milliseconds-of-the-Day
+ 16-bit Microseconds-within-millisecond (optional)

This is typically the time information we receive from ground hardware
and/or satellite onboard applications.
There's no problem with rounding here, seconds and sub-seconds can be
cleanly separated and nobody is going to even try asserting that e.g.
CUC "00000001:FFFFFF" sec could "legally" be displayed as "2.0sec" due to
rounding.

However sometimes we do have to output these times in "human readable"
format as hh:mm:ss.nnnnnn where 'nnn...' is either milliseconds or
microseconds. This is where the misery begins. Anyway as you say, as a
result of our forays into the "blessings" of TDateTime, we have already
established a policy to stick with the binary integer formats until the very
last stage of output.

--
Kristofer




.