Hi Pete,
I get what you said. But:
I'm nowhere near your timezone, I'm at 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?
I've switched curl so everything should work ok by now. According to my logs
I'm getting a new rulebase about every hour.
Met vriendelijke groet,
Bonno Bloksma
senior systeembeheerder
tio
hogeschool hospitality en toerisme
begijnenhof 8-12 / 5611 el eindhoven
t 040 296 28 28 / f 040 237 35 20
b.blok...@tio.nl / www.tio.nl
----- Original Message -----
From: Pete McNeil
To: Message Sniffer Community
Sent: Wednesday, March 11, 2009 1:57 PM
Subject: [sniffer] Re: New IMPROVED getRulebase.cmd script
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 minute.
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,
_M
