Bonno Bloksma wrote:
Why does this problem start just now with a DST shift somewhere? I'n
nowhere near your timezone (GMT+1 or +2) so should there not have been
a problem long before where my system would see older files at your
system several times a day when in fact there would be a newer one?
Does that mean my system has been getting only two or three updates a
day where it should have gotten over a dozen?
Unfortunately I disabled logging a while ago when everything seemed to
run smoothly. :-(
Someone to your west would have seen a new rulebase every time they
checked no matter what DST.
Or.... is it just that you finally noticed it due to the DST shift?
The reason DST is an issue is because the previous wget based script
stamps the downloaded rulebase with the local clock instead of the
timestamp that came with the file from the delivery server. As a result
the timestamps might not agree.
The recent change in the start of DST in the US is not reflected
everywhere AND some locations use different DST start dates. The result
of this is that when using the old script the local timestamp created
using the local clock is likely to be behind the delivery server's
timestamp by an hour.
The new update-script mechanism in SNFServer compares the local file's
timestamp to the timestamp reported by the delivery server once every
When the local timestamp is used and the local time is behind the clock
on the delivery server then the freshly downloaded rulebase file
_appears_ to be an hour old and this does not change no matter how many
times the file is downloaded.
Before DST the local clock and the delivery server's clock would
generally agree and so there was no problem.
Hope this helps,