commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Steve Cohen <>
Subject Re: [Net] Bug in FTPFile.Timestamp near end of month
Date Tue, 01 Feb 2005 12:50:44 GMT
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, 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 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:
For additional commands, e-mail:

View raw message