Our Products:   CompleteFTP  edtFTPnet/Free  edtFTPnet/PRO  edtFTPj/Free  edtFTPj/PRO
0 votes
7.6k views
in Java FTP by
for the code

ftp.chdir(ftp.pwd()+"/softwares");
Timestamp ts = new Timestamp (ftp.modtime "README_Postgres.txt").getTime());


System.out.println(ts.toString());

FTPFile s[] = ftp.dirDetails(".");
for (int i=0;i<s.length;i++)
{
System.out.println(s[i].getName());
System.out.println(s[i].lastModified().toString());
}

Console Output is

DEBUG [com.enterprisedt.net.ftp.FTPControlSocket] 21 Jul 2004 12:53:30.916 : 230 Login successful. Have fun.
DEBUG [com.enterprisedt.net.ftp.FTPControlSocket] 21 Jul 2004 12:53:30.916 : ---> PWD
DEBUG [com.enterprisedt.net.ftp.FTPControlSocket] 21 Jul 2004 12:53:30.976 : 257 "/home"
DEBUG [com.enterprisedt.net.ftp.FTPControlSocket] 21 Jul 2004 12:53:30.976 : ---> CWD /home/softwares
DEBUG [com.enterprisedt.net.ftp.FTPControlSocket] 21 Jul 2004 12:53:30.986 : 250 Directory successfully changed.
DEBUG [com.enterprisedt.net.ftp.FTPControlSocket] 21 Jul 2004 12:53:30.986 : ---> MDTM README_Postgres.txt
DEBUG [com.enterprisedt.net.ftp.FTPControlSocket] 21 Jul 2004 12:53:30.986 : 213 20040720094039
2004-07-20 15:10:39.0 <---(Value from modTime() )
DEBUG [com.enterprisedt.net.ftp.FTPControlSocket] 21 Jul 2004 12:53:30.996 : ---> SYST
DEBUG [com.enterprisedt.net.ftp.FTPControlSocket] 21 Jul 2004 12:53:31.6 : 215 UNIX Type: L8
DEBUG [com.enterprisedt.net.ftp.FTPControlSocket] 21 Jul 2004 12:53:31.6 : ---> PASV
DEBUG [com.enterprisedt.net.ftp.FTPControlSocket] 21 Jul 2004 12:53:31.26 : 227 Entering Passive Mode (172,20,13,173,50,142)
DEBUG [com.enterprisedt.net.ftp.FTPControlSocket] 21 Jul 2004 12:53:31.26 : ---> LIST .
DEBUG [com.enterprisedt.net.ftp.FTPControlSocket] 21 Jul 2004 12:53:31.26 : 150 Here comes the directory listing.
DEBUG [com.enterprisedt.net.ftp.FTPControlSocket] 21 Jul 2004 12:53:31.36 : 226 Directory send OK.
README_Postgres.txt
Tue Jul 20 09:40:00 GMT+05:30 2004 <-- (Value from dirDetails)

why am i getting 2 different dates for modification time of README_Postgres.txt file..

am i doing something wrong in the code...
plz help

4 Answers

0 votes
by (162k points)
modtime() returns the modified time of the file in GMT, as required by the FTP standard.

dirDetails() returns the modified time of the file in the timezone where the FTP server hosting the files is - it constructs the timestamp by parsing the dir listing.

So unless the FTP server is in a timezone that is GMT, they will be different.
0 votes
by
modtime() returns the modified time of the file in GMT, as required by the FTP standard.

dirDetails() returns the modified time of the file in the timezone where the FTP server hosting the files is - it constructs the timestamp by parsing the dir listing.

So unless the FTP server is in a timezone that is GMT, they will be different.


thanx for the ans
0 votes
by
But what's the sense in doing this?
Only times based on GMT can be compared to local files, since File.lastModified will also return a long in GMT. The time returned by dirDetails/FTPFile will always be wrong if the server doesn't use the exact same timezone/daylight saving as the local filesystem.
I helped myself by calculating the offset between the correct time returned by modtime and the one parsed by dirDetails for one file and applied it to every file. Thus it's possible to compare the times of the remote files with that of local files correctly. But this can't be the way it's meant to be.
0 votes
by (162k points)
There is no FTP standard for the listing returned which is parsed by dirDetails(). It is generally implemented by simply returning the listing from the O/S on the server. It isn't even required to have a timestamp.

modtime is a standard (sort of) - GMT. Not all FTP servers implement it.

It is always going to be problematic to compare the times of remote files with local ones.

If you are sending the files to the FTP server and retreiving them later, you can preserve timestamps by sending and retrieving as a zip file.

But what's the sense in doing this?
Only times based on GMT can be compared to local files, since File.lastModified will also return a long in GMT. The time returned by dirDetails/FTPFile will always be wrong if the server doesn't use the exact same timezone/daylight saving as the local filesystem.
I helped myself by calculating the offset between the correct time returned by modtime and the one parsed by dirDetails for one file and applied it to every file. Thus it's possible to compare the times of the remote files with that of local files correctly. But this can't be the way it's meant to be.

Categories

...