On Tue, 1 Nov 2011, zeljko 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.
IMO, better correct and slow than incorrect and fast (especially in this case ,
since 24/7 apps compiled with fpc aren't 24/7 apps anymore).
At least this must be documented in fpc until it's fixed or provided some kind
of workaround, eg that our 24/7 service (or any other app - doesn't matter
at all) can trigger rtl from time to time to read tzdata.
eg. imagine bool FpReadTZDataNextTime: Boolean = False; (global variable).
when we call fpgettimeofday() we check if FpReadTZDataNextTime is false/true.
It will be something like that, yes. I was thinking of introducing a
CheckRefreshTZInfoInterval: integer;
-1 : never check for refresh (current behaviour)
0 : refresh on each call (like LibC, will be new default)
0 : Only refresh every N [yourfavouriteinterval].
But of course not in fpgettimeofday, in EpochToLocalTime. I repeat:
fpgettimeofday returns UTC time, it does not need to read timezone info.
It is the step which converts this time to local time that must re-read the
timezone files if needed.
(EpochToLocalTime, the equivalent of localtime_r in libc)
However, meanwhile:
1. You can force a re-calculation of DST with the call (unix unit):
GetLocalTimezone(fptime);
This will not refresh the TZ data from file, but will re-calculate the DST
settings.
2. You can force a re-read of the timezone file with (unix unit):
ReadTimezoneFile(GetTimezoneFile);
Then you must still do the recalculation of DST.
These calls were already present in the RTL.
3. A more simple mechanism is using the (newly added) ReReadTimeZone (unix
unit):
ReReadTimeZone;
Which will re-read TZ and re-calculate DST settings all in one go.
I added this in revision 19569. The idea is that the new 'automation'
mechanism will call this routine.
Michael.
_______________________________________________
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
