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);
--
W. McDonald Buck <[EMAIL PROTECTED]>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
