That other thread "Time Stamping and Daylight Savings Time" reminded me of an issue, that I have been carrying around with me for quite a while and of which I thought would be worth clarifying and maybe also sorting out.
For a customer of mine I am keeping FTP mirrors of data files, the customer being located in Europe, the data files being fetched in the U.S., let's say New-England. As there is no proper and standard way to obtain the exact time stamp of a remote file through ftp, the respective directory listing is being parsed instead. But as FTP directory listings do not include the time zone, the files live in, (I think) wget just assumes the local time zone to be identical to the remote one. Am I right with this? As long as this concept is being kept to entirely, this is probably the best, that can be done. But it leads to a situation, that wget creates files with time stamps much older, than the files actually are. E.g. let's assume we now have 07:00 in Europe and 01:00 in New-England and the file, we are going to retrieve from New-England over to Europe, has a "New-England local" time stamp of 00:00. So when wget retrieves the file from New-England to Europe it is still being time-stamped by wget as 00:00 , but rather should that be a "Europe local" 06:00. A couple of hours later *I* am going to be asked this: we can see from the log files, that wget only retrieved the files at "Europe local" 07:00, although they apparently already were to ready to get picked up at 00:00. why is that? I wouldn't mind making wget believe (maybe through setting the environment variable "TZ") it actually "lives" in New-England, although it "lives" here in Europe. Would that be a reasonable approach or rather nonsense? JH
