Hope someone can help - this is driving me nuts. I'm on EST, and every file I upload has it's 'Date Modified' field re-written to PST on the server. File compare is now useless. Every file registers as modified, because every file is marked modified three hours behind the local time they were modified. So I have to scan every file timestamp w/my eyeballs for discrepancies. Is this hopeless or can timezone adjustments be set somewhere? I use SmartFTP and have set it to preserve all timestamps, but your server ignores it and rewrites the file-modified date to minus 3 hours.
The servers live in the Pacific time zone, and the timestamp for the files is local to the server, not to the source of the uploaded file. I'm afraid there isn't any way to change that on the server. Where are you doing the file compare? Maybe there's some way to set a three hour offset...?
thanks Michael, i did some testing this morning and the issue seems more complex than i initially thought and i suspect it's partially dependent on the FTP client in use. i forgot a couple important points: 1) i'm using SmartFTP 4.0.1234 Home edition (several years old). 2) i'm using FTPS protocol, which is definitely factoring into this issue. i connected using standard FTP and the DateModifieds are preserved at their original local times. local and remote completely match. this would solve the problem, but i lose encryption. so i only have this issue when using FTPS. when i connect via FTP, the remote files list in EST (match my local time). when i connect via FTPS, the remote files register in PST. in digging through the transfer logs, i note a descrepancy between the FTP LIST and STAT commands that SmartFTP issues: LIST (requests contents of a directory) renders all the DateModifieds in PST (3 hours behind my local). but if i select one file and call STAT (requests file properties) the properties window that renders shows the DateModified in EST, not PST. ___________________________________________________________ so to illustrate what's happening here - i use a test text file "time.txt" and upload it. this file's LOCAL LastMod time is 11:35AM EST. later i FTPS in and load the dir: Code: [15:06:32] Opening data connection to [...] [15:06:32] LIST -aL [15:06:32] 150 Opening ASCII mode data connection. [15:06:32] 226 Transfer complete. [15:06:32] 285 bytes transferred. (1.66 KB/s) (167 ms) that's the end of LIST command - which lists all files in the dir. the LastMod of 'time.txt' now appears as 08:35 AM (now its in WinHost server PST). so this is where my file comparison utility goes into the trash. now i request the file properties for 'time.txt' and get this response: Code: [15:06:53] TYPE I [15:06:53] 200 Type set to I. [15:06:53] SIZE time.txt [15:06:53] 213 91 [15:06:53] MDTM time.txt [15:06:53] 213 20160927153514 [15:06:53] STAT time.txt [15:06:53] 213-status of time.txt: [15:06:53] -[...] 1 owner group 91 Sep 27 8:35 time.txt [15:06:53] 213 End of status. note that 20160927 1535 (after the MDTM call) is the UTC time for the file... 15:35 UTC = 08:35 am PST STAT launches a SmartFTP properties window and it shows the LastMod time as 11:35, which is EST, not PST (differs from the log text there). and when i close this properties window, the LastMod date jumps from 08:35 to 11:35 in the SmartFTP file-listing window. lastly, if i call LIST again on the dir (refresh the folder contents), the 'time.txt' LastMod jumps from 11:35 back to 08:35. i'm plan to test FTPS using FileZilla and see if/how it differs.
