You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by "W. McDonald Buck" <de...@wmbuck.net> on 2005/02/01 07:16:45 UTC
[Net] Bug in FTPFile.Timestamp near end of month
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 <de...@wmbuck.net>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [Net] Bug in FTPFile.Timestamp near end of month
Posted by Steve Cohen <sc...@javactivity.org>.
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