[
https://issues.apache.org/jira/browse/NET-188?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12579187#action_12579187
]
Martin Oberhuber commented on NET-188:
--------------------------------------
I applied the patch, and it works fine for Feb.29.
But I see a problem when it is Dec.31 on the client computer, server is in a
different time zone and shows a date as Jan.01 -- in this case the result date
is rolled back a whole year. Here is a test case, that can be added to
FTPTimestampParserImplTest.java, and fails with both Commons.Net 1.4.1 as well
as HEAD as well as with the patch applied:
public void testParseJan01() throws Exception {
GregorianCalendar now = new GregorianCalendar(2007, Calendar.DECEMBER,
31, 12, 0);
checkShortParse("2007-12-31",now,now); // should always work
GregorianCalendar target = (GregorianCalendar) now.clone();
target.add(Calendar.DAY_OF_YEAR, +1);
checkShortParse("2008-1-1",now,target);
}
I think this is the kind of situation that was originally meant to address with
the setLenienFutureDates() method - See NET-83, comment on
FTPTimestampParserImpl is "Fix bug 35181 - add an option to specify leniency
when needed because client and server systems cannot be synchronized."
The right solution, IMHO, is to allow short dates +- 6 months in the future or
past, which seems to be in line with what FreeBSD is doing as well as what
Linux is doing. Note that allowing a short date in the future might require
adding "current year + 1" to the current Feb29 hack to fix a case where a
future date is a leap year on Feb.29.
> FTPClient#listFiles returns null element when file's timestamp is "02/29"
> -------------------------------------------------------------------------
>
> Key: NET-188
> URL: https://issues.apache.org/jira/browse/NET-188
> Project: Commons Net
> Issue Type: Bug
> Affects Versions: 1.4
> Reporter: HONMA Hirotaka
> Attachments: commons-net-ftp-date-parser-feb29.patch,
> DstParseTest.java, FTPTimestampParserLeap.patch
>
>
> This issue has same cause as VALIDATOR-221.
> org.apache.commons.net.ftp.parser.FTPTimestampParserImpl#parseTimestamp
> throws ParseException with timestampStr = "Feb 29 11:22".
> FTP Server status:
> {code}
> [EMAIL PROTECTED] test-commonsnet]# pwd
> /tmp/test-commonsnet
> [EMAIL PROTECTED] test-commonsnet]# ls -l
> total 0
> -rw-r--r-- 1 root root 0 Dec 19 2006 aaa.txt
> -rw-r--r-- 1 root root 0 Feb 29 11:22 bbb.txt
> {code}
> test code:
> {code}
> public void testCommonsNetLeapDay() throws Exception {
> final FTPClient ftp = new FTPClient();
> ftp.connect(host);
> ftp.login(user, password);
> final FTPFile[] listFiles = ftp.listFiles("/tmp/test-commonsnet");
> for (int i = 0; i < listFiles.length; i++) {
> System.out.println("[" + i + "] " + listFiles[i]);
> }
> ftp.disconnect();
> }
> {code}
> results bellow.
> {code}
> [0] -rw-r--r-- 1 0 0 0 Dec 18 2006 aaa.txt
> [1] null
> {code}
> Second element(bbb.txt) should not be null.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
