> 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. If I say in my app: SysUtils.FPReadTZDataNextTime := True; That will mean read tzdatadb in next call of fpgettimeofday() and then correct time if needed and set FPReadTZDataNextTime to false. In that case rtl stays clear and fast and it re-reads tzdata only when it's called from application. Not best solution , but can help a lot until final solution is found. zeljko
_______________________________________________ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
