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.
_______________________________________________
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
