What version of commons-net are you using?
The latest versions on the site (nightly build, source or binary) have a
fix for this problem. It explicitly lets you set a time zone for the
ftp server so that you can get correct dates. In fact, you who have a
real need for this functionality, would be an ideal person to try this
out. If you are interested I will happily help you through any
difficulties you may have with this, although I think you will find it
easy enough to use.
Steve Cohen
W. McDonald Buck wrote:
> I'm reporting a minor bug in UnixFTPEntryParser.java, in computing the
> timestamp for an FTPFile. I looked briefly at the parsers for the other
> systems, and didn't see a similar problem. I'm not subscribed to this
> list so please send any response by email.
>
> Scenario:
> It is January 31, 2005 at 10:00pm in Boulder, Colorado.
> I'm using org.apache.commons.net.ftp to parse a directory of files on a
> server 3 timezones to the east, comparing timestamps on the files using
> FTPFile.getTimestamp(). I'm getting a wrong answer.
>
> Problem: I'm looking at a file just created in Washington, D.C. and it
> is already February 1, 2005 there. The following code in
> UnixFTPEntryParser @ line 205 is wrong:
>
> // if the month we're reading is greater than now, it must
> // be last year
> if (cal.get(Calendar.MONTH) < month)
> {
> year--;
> }
> cal.set(Calendar.YEAR, year);
>
> At this point "month" contains the month number of the file, scanned off
> the returned ls. This code compares the remote file's month of creation
> to the current month on the local machine, and if greater than the local
> month, subtracts 1 from the year.
>
> Since the file I'm looking at was created moments ago in Washington,
> D.C. where it is already Feb 1, 2005, but it is still Jan 31, 2005 in
> Boulder, where the code is running, the test above subtracts 1 from the
> year, and sets the timestamp of the FTPFile to Feb 1, 2004 -- off by a
> year.
>
> A solution which allows for files in earlier timezones to be a few hours
> ahead will, of course, create a bug for files which are a few hours less
> than a year old in the current or lagging time zones. Is it fair to say
> that precision of measurement is more likely to be important on files a
> few hours old than on files already a year old? That is true for me at
> least.
>
> I'm not set up to send you a patch for this, but wouldn't it be simple
> just to add one day, to compensate for possible time zone differences,
> i.e. :
>
>> cal.add(Calendar.DAY_OF_MONTH,1);
>
> if (cal.get(Calendar.MONTH)<month)
> {
> year--;
> }
>
>> cal.add(Calendar.DAY_OF_MONTH,-1);
>
> cal.set(Calendar.YEAR, year);
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
|