[fpc-devel] Problem with Now() and time changed by ntpd

[Sven Barth]

Am 03.11.2011 17:38, schrieb Hans-Peter Diettrich:
> Sven Barth schrieb:
>
>> 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)
>
> That code doesn't make sense, without additional information :-(
>
> 283 do
> 284 {
> 285 SystemTime.HighPart = SharedUserData->SystemTime.High1Time;
> 286 SystemTime.LowPart = SharedUserData->SystemTime.LowPart;
> 287 }
> 288 while (SystemTime.HighPart != SharedUserData->SystemTime.High2Time);
>
> As long as no functions are involved, the loop copies the same
> information into SystemTime, over and over again.

As Vinzent wrote, the SystemTime field is considered volatile (take a 
look at %fpcdir%\rtl\nativent\ndk\ketypes.inc; I have kept the 
"volatile" keywords as comments when translating that _KUSER_SHARED_DATA 
struct). This code is also found throughout ReactOS (and I expect 
Windows as well) when the time is fetched inside one of the operating 
system components. I've basically copied this code for the GetLocalTime 
implementation of my NativeNT port and it definitely works and does not 
loop till the end of eternity :)

>>> 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.
>
> Then something like WinAPI SystemTimeToTzSpecificLocalTime has to be
> implemented. That function can be used for every platform, provided that
> the SystemTime is stored in an platform independent way.

Something like this, yes.

Regards,
Sven