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

[Michael Van Canneyt]

On Tue, 1 Nov 2011, Henry Vermaak wrote:

> On 01/11/11 11:08, Michael Van Canneyt wrote:
>> 
>> 
>> On Tue, 1 Nov 2011, Henry Vermaak wrote:
>> 
>>> On 01/11/11 10:30, Michael Van Canneyt wrote:
>>>> We'll simply need to store the next moment when the DST correction
>>>> changes, compare the result of gettimeofday with that and re-base the
>>>> time calculation. If we decide to add some check for the timestamp of
>>>> the timezone file - that would make Date(), Time() and Now() VERY
>>>> expensive operations.
>>> 
>>> This seems to be what libc does (from looking at an strace of some gcc
>>> binary).
>> 
>> Correct (I had checked as well), but the only purpose that serves is to
>> check whether the system timezone info has changed.
>> 
>> This is something that normally doesn't happen unless you move your
>> system from one timezone to another or during system setup, so I
>> question the desirability of this check.
>
> If you don't do this, daemons that were started before e.g. a daylight 
> savings update will report the wrong time after the update.  Rather solve 
> this correctly than take short cuts because you want to keep the time 
> functions "fast".  Someone can always add performance timing helpers that use 
> the correct functions on various OSes.

The problem with that is that a LOT of existing code contains many calls to 
Now() and Date(), because these calls are very cheap on Windows. If all these 
calls will suddenly cause a stat() of /etc/localtime, that's simply not acceptable, 
since that will cause a noticeable error in your reported time, as disk access 
is very slow and dependent on system load.

As I see it, it is a 2 step program:

1. First off, we must correctly take into account DST. That should fix Zejlko's problem.

2. Then we can include a variable to regulate the behaviour of detecting TZ definition
changes. (i.e. the Stat() call)

Michael.