Am 04.11.2011 12:50, schrieb Hans-Peter Diettrich:
But then I wonder why you *ever* want to convert TSystemTime into TDateTime, when it will be converted back again in the date/time formatting (and other) procedures. It would be much faster to display or write out a time stamp, based directly on TSystemTime.
Simple answer: all time/date handling in Delphi/FPC is BASED ON the TDateTime type.
POSIX gettimeofday() instead does not return a decoded date/time, so that Delphi uses localtime_r() to decode it. The inverse function must be used then, to decode a TDateTime for display and other date/time handling. When the RTL implements both these procedures, there should not remain any time difference in the Now() and other procedures on Windows and Linux, based on something like an tick count.
But Delphi also converts the date/time returned by localtime_r() to a TDateTime, because - as I've written above - that is what Delphi's RTL, VCL and FireMonkey use as date/time type. Also there will still be a time difference as the retrieval of the time zone information on Linux (and other POSIX systems) requires access to a file while on Windows simply the time zone bias in RAM is used. And also basing Now() on a tick count is a bad idea as now is defined as returning the current (local) date and time instead of some monotonic value like the time since the system was started (what GetTickCount on Windows is).
Regards, Sven _______________________________________________ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
