You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@commons.apache.org by "Andre Sudhoff (JIRA)" <ji...@apache.org> on 2008/05/13 18:59:56 UTC

[jira] Issue Comment Edited: (NET-188) FTPClient#listFiles returns null element when file's timestamp is "02/29"

    [ https://issues.apache.org/jira/browse/NET-188?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12596445#action_12596445 ] 

sumauan edited comment on NET-188 at 5/13/08 9:59 AM:
------------------------------------------------------------

I've done another fix for the leap year problem. This should work regardless which is the correct year for the 29. Feb (this year or last year).
See attached file "FTPTimestampParserImpl.patch"

Index: FTPTimestampParserImpl.java
===================================================================
--- FTPTimestampParserImpl.java	(revision 473)
+++ FTPTimestampParserImpl.java	(working copy)
@@ -41,6 +41,7 @@
 	
 	private SimpleDateFormat defaultDateFormat;
 	private SimpleDateFormat recentDateFormat;
+	private SimpleDateFormat recentWithYearDateFormat;
 	
 	
 	/**
@@ -75,35 +76,62 @@
 		ParsePosition pp = new ParsePosition(0);
 
 		Date parsed = null;
-		if (this.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 (working.after(now)) {
-				working.add(Calendar.YEAR, -1);
-			}
-		} else {
+		if (recentWithYearDateFormat != null) {
+			//For the 29. Feb of a leap year we have to parse with the correct year because
+			//parsing without a year defaults to 1970 which is not a leap year, then the parsing fails or we get the 1 of mrach
+			String timestamWithYearStr = timestampStr.trim() + " " + now.get(Calendar.YEAR);
 			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()) {
+			parsed = recentWithYearDateFormat.parse(timestamWithYearStr, pp);
+			if (parsed != null && pp.getIndex() == timestamWithYearStr.length()) {
 				working.setTime(parsed);
+				working.set(Calendar.YEAR, now.get(Calendar.YEAR));
+				if (working.after(now)) {
+					working.add(Calendar.YEAR, -1);
+				}
+				
+				return working;
 			} else {
-				throw new ParseException(
-					"Timestamp could not be parsed with older or recent DateFormat", 
-					pp.getIndex());
+				timestamWithYearStr = timestampStr.trim() + " " + (now.get(Calendar.YEAR) - 1);
+				pp = new ParsePosition(0);
+				parsed = recentWithYearDateFormat.parse(timestamWithYearStr, pp);
+				if (parsed != null && pp.getIndex() == timestamWithYearStr.length()) {
+					working.setTime(parsed);
+					return working;
+				}
 			}
+		} else if (this.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 (working.after(now)) {
+					working.add(Calendar.YEAR, -1);
+				}
+				
+				return working;
+			}
 		}
-		return working;
+		
+		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);
+			
+			return working;
+		}
+			
+
+		throw new ParseException(
+				"Timestamp could not be parsed with older or recent DateFormat", 
+				pp.getIndex());
 	}
 
 	/**
@@ -146,6 +174,11 @@
 		if (format != null) {
 			this.recentDateFormat = new SimpleDateFormat(format);
 			this.recentDateFormat.setLenient(false);
+			
+			if (format.indexOf("y") == -1) {
+				this.recentWithYearDateFormat = new SimpleDateFormat(format.trim() + " yyyy");
+				this.recentWithYearDateFormat.setLenient(false);
+			}
 		}
 	}
 	
@@ -179,6 +212,9 @@
 		if (this.recentDateFormat != null) {
 			this.recentDateFormat.setTimeZone(serverTimeZone);
 		}			
+		if (this.recentWithYearDateFormat != null) {
+			this.recentWithYearDateFormat.setTimeZone(serverTimeZone);
+		}			
 	}
 	
 	/**
@@ -223,6 +259,11 @@
 		} else {
 			this.recentDateFormat = new SimpleDateFormat(recentFormatString, dfs);
 			this.recentDateFormat.setLenient(false);
+
+			if (recentFormatString.indexOf("y") == -1) {
+				this.recentWithYearDateFormat = new SimpleDateFormat(recentFormatString.trim() + " yyyy", dfs);
+				this.recentWithYearDateFormat.setLenient(false);
+			}
 		}
 			
 		String defaultFormatString = config.getDefaultDateFormatStr();



      was (Author: sumauan):
    I've done another fix for the leap year problem. This should work regardless which is the correct year for the 29. Feb (this year or last year).
  
> 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, FTPTimestampParserImpl.patch, 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}
> [root@localhost test-commonsnet]# pwd
> /tmp/test-commonsnet
> [root@localhost 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.