Download
2011-03-21, 22:46:54
Sorry, it was only post #5 that I was unsure about.
Timezone: yes, I think this could be a problem for a site that isn't expecting to be in UTC+5 and uses php for critical date stuff. More importantly, the fact that there is some sort of unexpected and undocumented TZ manipulation of the server's php environment.
Site Archive filenames: (this was the bit that I was addressing in post #5) I'm trying to get a better idea of what's happening. There are a couple of other (minor, I guess) problems --. e.g., if two different admins are in different TZs, not so uncommon these days, whose TZ is used in order to avoid dates in the future for one of them; if two backups are made within the same minute, the first is overwritten.
Using UTC throughout would solve some of this, but then give rise to user confusion, no doubt. A timestamp to include the real-time seconds would solve the overwriting, but the function lngDate() can't handle that at the moment.
Timezone: yes, I think this could be a problem for a site that isn't expecting to be in UTC+5 and uses php for critical date stuff. More importantly, the fact that there is some sort of unexpected and undocumented TZ manipulation of the server's php environment.
Site Archive filenames: (this was the bit that I was addressing in post #5) I'm trying to get a better idea of what's happening. There are a couple of other (minor, I guess) problems --. e.g., if two different admins are in different TZs, not so uncommon these days, whose TZ is used in order to avoid dates in the future for one of them; if two backups are made within the same minute, the first is overwritten.
Using UTC throughout would solve some of this, but then give rise to user confusion, no doubt. A timestamp to include the real-time seconds would solve the overwriting, but the function lngDate() can't handle that at the moment.
--
Nick.
Nick.
