Am 03.11.2011 03:12, schrieb Hans-Peter Diettrich:
Also note that on platforms like Windows this would be a unnecessary
call as there the current(!) timezone bias is located in a shared
memory area which is mapped into each process by the kernel.
I don't think that this really is how Windows works. Delphi Now()
retrieves an TSystemTime record (GetLocalTime), and converts its fields
into an TDateTime value(EncodeDate/Time). A simple timezone bias is
inapplicable to the TSystemTime data structure, but the kernel.dll may
keep its conversion information somewhere in the DATA segment.
FPC's Now on Windows uses GetLocalTime as well. For its implementation
please take a look here:
http://svn.reactos.org/svn/reactos/trunk/reactos/dll/win32/kernel32/client/time.c?revision=52912&view=markup
(line 277ff)
The application of the timezone bias is from line 290 to 300. If there
is no redirection of the time zone (used for terminal servers) then the
bias is read from the beforementioned shared user data.
Here is the implementation of "SharedUserData" in my NativeNT port of
FPC (unit NDK):
=== source begin ===
function SharedUserData: PKUSER_SHARED_DATA; register;
begin
{ this is a pointer to a page that is mapped into every process by
the kernel
}
SharedUserData := PKUSER_SHARED_DATA(USER_SHARED_DATA);
end;
=== source end ===
And USER_SHARED_DATA has the following value:
=== source begin ===
USER_SHARED_DATA = $7FFE0000;
=== source end ===
On POSIX
platforms gettimeofday and localtime_r is used instead (Delphi XE). All
this handling makes Now() quite expensive, so that (a future) FPC should
provide cheaper means for getting time stamps.
The problem with localtime_r itself is that it's implemented in LibC
which must be avoided for the non-LibC-RTL. So FPC definitely must
provide an implementation of its own for this.
Regards,
Sven
_______________________________________________
fpc-devel maillist - [email protected]
http://lists.freepascal.org/mailman/listinfo/fpc-devel
