[ http://issues.apache.org/jira/browse/VALIDATOR-154?page=all ]
Niall Pemberton updated VALIDATOR-154:
--------------------------------------
Fix Version/s: 1.3.1
Assignee: Niall Pemberton
> [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
> Assigned To: Niall Pemberton
> Priority: Minor
> Fix For: 1.3.1
>
> 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
