Bonno Bloksma wrote:
Hi Pete,
In your first mail about this problem you wrote:
/There has long been a bug in the getRulebase script using wget which
causes the rulebase file that is downloaded to have the local system's
timestamp. Under normal circumstances this does not cause a problem
because most system clocks are synchronized and the local timestamp is
generally newer than the timestamp of the rulebase file on our servers.
/
What I was getting at:
If the rulebase with the old wget software were to get a local
timestamp on my server when downloaded, mine would always be "far"
into the future from your original as my server is at GMT+1 or +2
during DST.
So if your server is at GMT-5 my rulebase would get a timestamp of the
original +6 hours. So it would then NOT download another rulebase for
the next 6 hours as every new rulebase would still be in it's past.
When comparing timestamps of files across systems the apparent UTC
timestamp is used (generally).
When displaying timestamps of files the underlying UTC timestamp is
converted to the local time (generally).
The first problem with using the local timestamp when downloading a
rulebase file is that the timestamp on the local file will be later than
the timestamp of the file on the server. This can delay your updates
(even when the system clocks are synchronized and working correctly).
Consider:
New rulebase is created at UTC 0100
Download occurs near 0130 and rulebase is given local timestamp of 0131.
New rulebase is created at UTC 0130
Download does not occur because local timestamp is later than server
timestamp.
That scenario is clearly going to be a rare occurrence when system
clocks are aligned and download processing is quick... but if a clock is
not synchronized and the time on the local server is shifted in some way
the window of opportunity for missed updates increases.
I realize this is splitting hairs a bit-- After all a missed rulebase
update will only increase leakage a bit and a later update will fix that
soon enough.
None the less, it is more correct to stamp the downloaded file with it's
original time and thereby eliminate any possibility of problems
associated with system clock differences or download processing time.
That is the best solution.
Or.... should wget have compensated for timezones as should curl?
Because my rulebase files on my server seem to have a local timestamp.
However, this is where we probably get beond my techlevel.
Does Windows allways use UTC internally and then calculate the local
time when displaying the timestamp for a file?
Is that what I'm missing? Because I think I've read that somewhere
about problems with timestamps on FAT and NTFS.
Is this what you mean? http://support.microsoft.com/kb/127830
I believe that windows uses UTC internally and checks that against the
system's RTC every hour or so to see if the time is accurate. What you
see when you look at a timestamp is converted to local time based on
your settings.
_M
