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

[michael.vancanneyt at wisa.be]

On Wed, 2 Nov 2011, zeljko wrote:

> On Wednesday 02 of November 2011 11:23:10 michael.vancanneyt at wisa.be wrote:
>> On Wed, 2 Nov 2011, Jonas Maebe wrote:
>>> Marco van de Voort wrote on Wed, 02 Nov 2011:
>>>> The point was just some encouragement to look further than the immediate
>>>> need though, and keep the time call relatively cheap. That doesn't
>>>> exclude being correct, it just means a more elaborate implementation.
>>>
>>> I do not think that reporting the time correctly taking into account the
>>> current time zone and daylight savings time is a function that needs to
>>> be treated as performance-critical.
>>
>> Under some (not so uncommon) circumstances it is, e.g. for logging
>> facilities. Our own eventlog facility would suffer from this.
>>
>>>> But harddisk latency can easily be in the half a second to second
>>>> magnitude (and then I don't even count spindowns, and am I accessing
>>>> directories that I continously access).
>>>
>>> If you are stat'ing that file for changes all the time, either the result
>>> will be cached or the hard drive won't spin down. And stat'ing a file
>>> will not take half a second when done repeatedly.
>>
>> I tested this yesterday, using the following sequence:
>>
>> fpGettimeOfDay();
>> if UseStat then
>>    fpStat('/etc/timezone');
>> fpGetTimeOfDay();
>
> Please see results about Now() and something that I've mentioned about
> deprecitation of gettimeofday().According to this test, current
> fpgettimeofday() is crap when compared with clock_gettime() (kernel) or libc
> calls (I've copied scenario from kylix sysutils).
>
> *Kernel clock_gettime() NowReal() with 10000000 calls = 4870 ms

You must do also a localtime_r after this call.
clock_gettime returns the same time as gettimeofday.

Michael.