Allan Fernandes wrote:
Is there any other method to store the datetime in Long format and
retain the precision to the second.
Rather than store the individual date/time components, you could store
an offset from a given epoch.
For example, Unix timestamps are expressed as the number of seconds
that have elapsed since January 1 1970 00:00:00 UTC. The RTL does have
DateTimeToUnix() and UnixToDateTime() functions, though the Unix times
are expressed as Int64 instead of Integer (as 32-bit Unix timestamps
can't exceed January 19 2038 03:14:08 UTC).
This is to do with a Compression utility written in Delphi whose
source code I have.
That means you are limited to whatever date/time format the compression
library expects you to use. Does it use DOS timestamps, Unix
timestamps, or something else? You have the source code, how does it
use the Date and Time values?
The Central Directory expects the date separately and time separately
in Long format.
You didn't say that earlier. You made it sound like you have to store
both Date and Time into a single Long. A DOS timestamp can do that,
but with lose of precision. But separating Date and Time into separate
Longs makes a big difference, because that gives you much more bits to
work with. You can bit-stuff the components of a TDate into a Long,
and bit-stuff the componnets of a TTime (down to milliseconds) into a
Long. Or you could convert a TDateTime to Unix Int64 and then split
its bits into 2 Longs. Or, since TDateTime is an 8-byte Double to
begin wtih, you could simply type-cast it to Int64 and split its bits
into 2 Longs.
--
Remy Lebeau (TeamB)
Connect with Us