Greetings,
[using CoreFTP 1.3c, Build 1437 on Win XP SP2]
I've read in other forum posts tales of woe related to file timestamps and MDTM. I have a similar problem, and a proposed solution.
Example: I have a file on my computer dated 2005/12/28 11:37; CoreFTP displays the date and time correctly in the local file list. I live in the Eastern time zone (GMT-0500 in the winter, GMT-0400 in the summer). When I upload this file, the log shows the following:
TYPE A
200 Switching to ASCII mode.
PASV
227 Entering Passive Mode (206,191,0,215,31,128)
STOR nav.htm
Connect socket #800 to 206.191.0.215, port 8064...
150 Ok to send data.
226 File receive OK.
nav.htm - 3326 bytes transferred
MDTM 20051228163748 nav.htm
213 File modification time set.
Note that the MDTM command sent by CoreFTP has my file time converted to GMT. Unfortunately, my ISP's FTP server interprets the time provided in the MDTM command as local time, not GMT. So on the server, the time gets set to 16:37 (i.e. 5 hours later than the actual time). Whenever I subsequently connect to the server, the file time appears as 16:37 in the remote file list (and also to other clients such as Windows' command line FTP client).
For files which are uploaded immediately after being updated, this behaviour is particularly awkward, because the timestamp of the file on the server is actually about 5 hours into the future. The time displayed in the remote file list for these files shows the date (which could be one day in the future, if the file was updated after 7:00 pm), but the time is displayed as 00:00.
I can work around part of this problem by setting the "Hour offset" option to "-5". This makes older files display correctly, but new files display incorrectly for 5 hours. It also means that the actual times on the server are still wrong, and will appear so to any third party client examining the directory.
The problem seems to be that CoreFTP always converts the file time to GMT when sending the MDTM command, but not all servers interpret the time provided as GMT (even if they should). The solution I propose is to provide a "Use local time for MDTM" option on the Transfers tab, next to "Do not use MDTM for date/time". The new option should not be selected by default, but if selected would mean that the server's MDTM expects (and reports) file timestamps as local times.
Please tell me that you'll consider implementing this suggestion (or something similar) sometime soon. It would get rid of a significant annoyance which seems to have plagued quite a few people.
Thank you.