[
https://issues.apache.org/jira/browse/NET-188?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12579253#action_12579253
]
Martin Oberhuber commented on NET-188:
--------------------------------------
I'd suggest that in terms of API, when a programmer knows the exact behavior of
the server, he should be able to get exact timestamps even if they are short
and/or in the future. Right now we know that FreeBSD does +-6-month short
dates; Linux RHEL4 does +0/-6-month short dates.
So what about a new API like
<code>
FTPClientConfig#setShortDateRange(long msecPast, long msecFuture)
</code>
that specifies in what range of time difference a short date is considered to
be in the past, or in the future respectively. The Javadoc comment could be
similar to the #setLenientFutureDates() method.
The old setLenientFutureDates(boolean) method could be deprecated, and
translated into this:
<code>
if(lenientFutureDates) {
setShortDateRange(1000L * 86400 * 364, 1000L * 86400);
} else {
setShortDateRange(1000L * 86400 * 365, 0);
}
</code>
I'm not completely sure what would be the best default value for the new
settings. Given that lenientFutureDates was false by default, we should
probably always expect dates in the past only by default. On the other hand,
given that a "one day in future" date is much more likely due to time zone
differences than a "365 days in the past" short date, a setting of +1 day /
-364 days might be a more appropriate default.
As a matter of fact, we cannot ever guarantee correct parsing when the user has
not specified by API what the setting should be. So the goal of a good default
setting could either be "avoid invalid dates even if a parse error occurs" (not
expected by the average user, IMHO, as the Feb.29 case shows); or, "always fall
back to a reasonable date as it would be read by the user, even if it might be
incorrect".
Given that the original RFC for FTP says "The output of DIR is designed for
human readers and might not be machine readable", I think the default should be
guided by what a human user would expect from the listing. That being said, I
think that when it's March 15 and I'm reading "March 16" I'd expect a future
date; reading "March 20" I'd expect a past date; so I'm in favor of a "+1 day /
-364 days" strategy by default.
Which is, admittedly, breaking the previous behavior which was lenientFuture ==
false meanding a +0 / -365 strategy.
> 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, jan01.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.
