[jira] Updated: (VALIDATOR-154) [validator] GenericValidator.isDate can fail when strict == true

["Niall Pemberton (JIRA)" <ji...@apache.org>]

     [ http://issues.apache.org/jira/browse/VALIDATOR-154?page=all ]

Niall Pemberton updated VALIDATOR-154:
--------------------------------------

    Component/s: Routines

> [validator] GenericValidator.isDate can fail when strict == true
> ----------------------------------------------------------------
>
>                 Key: VALIDATOR-154
>                 URL: http://issues.apache.org/jira/browse/VALIDATOR-154
>             Project: Commons Validator
>          Issue Type: Improvement
>          Components: Routines
>    Affects Versions: Nightly Builds
>         Environment: Operating System: All
> Platform: All
>            Reporter: Gregg Yost
>            Priority: Minor
>         Attachments: date-patches.zip
>
>
> org.apache.commons.validator.GenericValidator.isDate(String value, String 
> datePattern, boolean strict) fails in some situations when the "strict" 
> parameter is true (it can either accept invalid dates or reject valid ones).  I 
> detected this in 1.0.2 but the latest code in CVS seems to have the same 
> problem (though in the latest code, the problem code has moved from 
> GenericValidator to DateValidator).
> The problem is that the "strict == true" is implemented by comparing the length 
> of the input string to the length of the pattern string.  This heuristic fails 
> in some situations.  For example:
>   - datePattern = "yyyy-MM-dd", value = "2003-06-2x" returns that the date is 
> valid but it isn't.  SimpleDateFormat parses the "2003-06-2" part as June 2, 
> 2003 even when setLenient(false) has been called, and the value and pattern 
> lengths are the same so the "strict" test passes.
>   - datePattern = "MMM dd, yyyy", value = "January 12, 2003" returns that the 
> date is NOT valid but it is.  The date parses correctly but the pattern and 
> value lengths are different, so the "strict" test doesn't pass.
> Both problems can be fixed by changing the implementation of "strict == true" 
> to see whether after the date has been parsed, the ParsePosition is at the end 
> of the input value string.
> Here's some sample code that should work correctly for the 
> DateValidator.isValid method in the latest source code.  Similar code would 
> work in version 1.0.2 in GenericValidator.isDate.  You should consider whether 
> the version of isValid that takes a Locale as a parameter is working as 
> intended as well (maybe it is, since it doesn't have a "strict" parameter -- 
> but should there be a way to specify both "strict" and a Locale?)
>   public boolean isValid(String value, String datePattern, boolean strict) {
>     if (value == null || datePattern == null || datePattern.length() <= 0) {
>       return false;
>     }
>     SimpleDateFormat formatter = new SimpleDateFormat(datePattern);
>     formatter.setLenient(false);
>     ParsePosition pos = new ParsePosition(0);
>     formatter.parse(value, pos);
>     if (strict && (pos.getIndex() < value.length())) {
>       return false;
>     }
>     return true;
>   }

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org