DO NOT REPLY [Bug 27414] New: - GenericValidator.isDate can fail when strict == true

[bu...@apache.org]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://nagoya.apache.org/bugzilla/show_bug.cgi?id=27414>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=27414

GenericValidator.isDate can fail when strict == true

           Summary: GenericValidator.isDate can fail when strict == true
           Product: Commons
           Version: 1.0.2
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: Normal
          Priority: Other
         Component: Validator
        AssignedTo: commons-dev@jakarta.apache.org
        ReportedBy: gyost@alumni.carnegiemellon.edu


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;
  }

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