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
FTPClientConfig#setShortDateRange(long msecPast, long msecFuture)
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:
setShortDateRange(1000L * 86400 * 364, 1000L * 86400);
setShortDateRange(1000L * 86400 * 365, 0);
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.