Your best friend for file transfer.
Fetch
Mirroring doesn't handle time zones (4 posts)
- Started 21 years ago by dand
- Latest reply 21 years ago from Jim Matthews
-
dand Member
-
Jim Matthews Administrator
You're right, the MDTM response is supposed to be in GMT, and that should eliminate time zone problems in mirroring.
In this case the server's response to the MDTM command is that the file was last modified 20030105221702, or January 5, 2003, 10:17 PM GMT. Japan is 9 hours ahead of GMT, so that translates to January 6, 2003, 7:17 AM local time in Japan. So Fetch saw the copy of the file on your hard disk, with a local modification time of 12:16 PM, and it looked newer than the copy on the server.
It looks like the server is using its local time (EST, 5 hours behind GMT and 14 hours behind Japan) in response to the MDTM command. That accounts for the 5 hour difference between the two modification times, and for the fact that the times in the file list (which are usually in local time) match the MDTM response. So either the server thinks its in GMT, or MDTM was implemented incorrectly. I would suggest contacting the server administrator about this.
Thanks,
Jim Matthews
Fetch Softworks -
dand Member
Ah I see. Thanks for the quick response. I'll check with the server admin. So Fetch actually uses the GMT modification date on local files, correct? Good job :)
Daniel
-
Jim Matthews Administrator
Yes, Fetch uses the GMT modification date on local files, if it has a GMT modification date from the server. If GMT information is unavailable Fetch puts in a 23-hour fudge factor to account for the maximum possible difference between two time zones.
Thanks,
Jim Matthews
Fetch Softworks
- Page 1
Topic closed
This topic has been closed.
When mirroring from a local folder to a remote server directory, Fetch compares dates on the remote files (eastern US time in my case) with modification dates of local files using presumably the local time (Japan time). Therefore, if I upload a file within 14 hours of editing it locally, then whenever I do a mirror of that directory that file gets uploaded even if it hasn't been edited.
I read somewhere that the MDTM command is supposed to take care of time zones, so if Fetch uses the GMT modification date instead of the local time for local files then this problem should be fixed... maybe?
Here's the transcript. The file in question, test.txt, shows as having modification date Jan. 6, 2003, 0:16PM in the Mac OS X 10.2.3 Finder (this is in Japan time). (I've cut some parts out.)
***Transcript***
Fetch 4.0.3 System 0x1023 Serial FETCHED001-****-**** TR
Connecting to pubbawup.net port 21 (1/6/03 0:10:58 PM)
220 ProFTPD 1.2.6 Server (ProFTPD) [server.wwwroot3.net]
ADAT
500 ADAT not understood.
USER dand@pubbawup.net
331 Password required for dand@pubbawup.net.
PASS
230 User dand@pubbawup.net logged in.
SYST
215 UNIX Type: L8
PWD
257 "/" is current directory.
MACB ENABLE
500 MACB not understood.
......snip......
PWD
257 "/mirror_test" is current directory.
PORT 192,168,0,4,189,6
200 PORT command successful
LIST -al
150 Opening ASCII mode data connection for file list
drwxr-xr-x 2 pubbawup pubbawup 4096 Jan 5 22:17 .
drwxr-xr-x 15 pubbawup pubbawup 4096 Jan 5 22:17 ..
-rw-r--r-- 1 pubbawup pubbawup 18 Jan 5 22:17 test.txt
226 Transfer complete.
MDTM test.txt
213 20030105221702
PORT 192,168,0,4,157,151
200 PORT command successful
STOR test.txt
150 Opening ASCII mode data connection for test.txt
226 Transfer complete.
Upload complete at 1/6/03 0:18:20 PM
CWD /mirror_test
250 CWD command successful.
PWD
257 "/mirror_test" is current directory.
PORT 192,168,0,4,57,207
200 PORT command successful
LIST -al
150 Opening ASCII mode data connection for file list
drwxr-xr-x 2 pubbawup pubbawup 4096 Jan 5 22:17 .
drwxr-xr-x 15 pubbawup pubbawup 4096 Jan 5 22:17 ..
-rw-r--r-- 1 pubbawup pubbawup 18 Jan 5 22:18 test.txt
226 Transfer complete.
PWD
257 "/mirror_test" is current directory.
Posted 21 years ago #