You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@commons.apache.org by rw...@apache.org on 2008/02/26 17:37:10 UTC
svn commit: r631284 -
/commons/proper/net/branches/NET_2_0/src/main/java/org/apache/commons/net/ftp/parser/FTPTimestampParserImpl.java
Author: rwinston
Date: Tue Feb 26 08:37:08 2008
New Revision: 631284
URL: http://svn.apache.org/viewvc?rev=631284&view=rev
Log:
Net-188: Attempt ugly hack to handle leap year dates without year specifier, attempt #1
Modified:
commons/proper/net/branches/NET_2_0/src/main/java/org/apache/commons/net/ftp/parser/FTPTimestampParserImpl.java
Modified: commons/proper/net/branches/NET_2_0/src/main/java/org/apache/commons/net/ftp/parser/FTPTimestampParserImpl.java
URL: http://svn.apache.org/viewvc/commons/proper/net/branches/NET_2_0/src/main/java/org/apache/commons/net/ftp/parser/FTPTimestampParserImpl.java?rev=631284&r1=631283&r2=631284&view=diff
==============================================================================
--- commons/proper/net/branches/NET_2_0/src/main/java/org/apache/commons/net/ftp/parser/FTPTimestampParserImpl.java (original)
+++ commons/proper/net/branches/NET_2_0/src/main/java/org/apache/commons/net/ftp/parser/FTPTimestampParserImpl.java Tue Feb 26 08:37:08 2008
@@ -72,44 +72,62 @@
public Calendar parseTimestamp(String timestampStr) throws ParseException {
Calendar now = Calendar.getInstance();
now.setTimeZone(this.getServerTimeZone());
-
+
Calendar working = Calendar.getInstance();
- working.setTimeZone(this.getServerTimeZone());
+ working.setTimeZone(getServerTimeZone());
ParsePosition pp = new ParsePosition(0);
Date parsed = null;
- if (this.recentDateFormat != null) {
+ if (recentDateFormat != null) {
parsed = recentDateFormat.parse(timestampStr, pp);
}
if (parsed != null && pp.getIndex() == timestampStr.length())
{
working.setTime(parsed);
working.set(Calendar.YEAR, now.get(Calendar.YEAR));
-
- if (this.lenientFutureDates) {
- // add a day to "now" so that "slop" doesn't cause a date
- // slightly in the future to roll back a full year. (Bug 35181)
- now.add(Calendar.DATE, 1);
+
+ if (lenientFutureDates) {
+ // add a day to "now" so that "slop" doesn't cause a date
+ // slightly in the future to roll back a full year. (Bug 35181)
+ now.add(Calendar.DATE, 1);
}
if (working.after(now)) {
working.add(Calendar.YEAR, -1);
}
} else {
- pp = new ParsePosition(0);
- parsed = defaultDateFormat.parse(timestampStr, pp);
- // note, length checks are mandatory for us since
- // SimpleDateFormat methods will succeed if less than
- // full string is matched. They will also accept,
- // despite "leniency" setting, a two-digit number as
- // a valid year (e.g. 22:04 will parse as 22 A.D.)
- // so could mistakenly confuse an hour with a year,
- // if we don't insist on full length parsing.
- if (parsed != null && pp.getIndex() == timestampStr.length()) {
+ // Temporarily add the current year to the short date time
+ // to cope with short-date leap year strings.
+ // e.g. Java's DateFormatter will assume that "Feb 29 12:00" refers to
+ // Feb 29 1970 (an invalid date) rather than a potentially valid leap year date.
+ // TODO This is a HORRENDOUS hack. Remove at first opportunity.
+ if (recentDateFormat != null) {
+ pp = new ParsePosition(0);
+ int year = Calendar.getInstance().get(Calendar.YEAR);
+ String timeStampStrPlusYear = timestampStr + " " + year;
+ SimpleDateFormat hackFormatter = new SimpleDateFormat(recentDateFormat.toPattern() + " yyyy");
+ hackFormatter.setLenient(false);
+ parsed = hackFormatter.parse(timeStampStrPlusYear, pp);
+ }
+ if (parsed != null && pp.getIndex() == timestampStr.length() + 5) {
working.setTime(parsed);
- } else {
- throw new ParseException(
- "Timestamp could not be parsed with older or recent DateFormat",
- pp.getIndex());
+ }
+ else {
+ pp = new ParsePosition(0);
+ parsed = defaultDateFormat.parse(timestampStr, pp);
+ // note, length checks are mandatory for us since
+ // SimpleDateFormat methods will succeed if less than
+ // full string is matched. They will also accept,
+ // despite "leniency" setting, a two-digit number as
+ // a valid year (e.g. 22:04 will parse as 22 A.D.)
+ // so could mistakenly confuse an hour with a year,
+ // if we don't insist on full length parsing.
+ if (parsed != null && pp.getIndex() == timestampStr.length()) {
+ working.setTime(parsed);
+ } else {
+ throw new ParseException(
+ "Timestamp could not be parsed with older or recent DateFormat",
+ pp.getIndex());
+ }
}
}
return working;
Re: svn commit: r631284 - /commons/proper/net/branches/NET_2_0/src/main/java/org/apache/commons/net/ftp/parser/FTPTimestampParserImpl.java
Posted by sebb <se...@gmail.com>.
On 29/02/2008, Jake Harmon <ja...@gfigroup.com> wrote:
>
> I don't think this will work, because in Jan 2009, if you get a file from Feb
> 29 and try to parse it using the current year, it will also fail.
I don't think this can happen unless the remote system clock is wrong.
The remote file obviously cannot be Feb 29, 2009, nor can it be Feb
29, 2008, because that is more than 6 months before Jan 2009. I.e.
*nix systems would display the year rather than the time.
Of course if the remote system thinks the time is Feb 29, 2008 +/- 6
months, then it will display the file details without a year.
> --
> View this message in context: http://www.nabble.com/svn-commit%3A-r631284----commons-proper-net-branches-NET_2_0-src-main-java-org-apache-commons-net-ftp-parser-FTPTimestampParserImpl.java-tp15694399p15766239.html
> Sent from the Commons - Dev mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: svn commit: r631284 -
/commons/proper/net/branches/NET_2_0/src/main/java/org/apache/commons/net/ftp/parser/FTPTimestampParserImpl.java
Posted by Jake Harmon <ja...@gfigroup.com>.
I don't think this will work, because in Jan 2009, if you get a file from Feb
29 and try to parse it using the current year, it will also fail.
--
View this message in context: http://www.nabble.com/svn-commit%3A-r631284----commons-proper-net-branches-NET_2_0-src-main-java-org-apache-commons-net-ftp-parser-FTPTimestampParserImpl.java-tp15694399p15766239.html
Sent from the Commons - Dev mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org