Allan Fernandes wrote:


It is not a bug. The DOS date/time format is not a precise format. It
has no miliseconds at all, and seconds are divided by 2 (see the
documentation for the FileTimeToDosDateTime() function on MSDN for the
exact format:
https://msdn.microsoft.com/en-us/library/windows/desktop/ms724274.aspx).
So, when you convert a file's date/time to DOS format via
DateTimeToFileDate() or the deprecated FileAge(), there is a loss of
precision, which is mirrored in FileDateToDateTime(). That is what you
are seeing.

--
Remy Lebeau (TeamB)

Allan Fernandes wrote:


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).


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?


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)