JDK-4266783 : java.util.GregorianCalendar: incorrect validation in non-lenient
  • Type: Bug
  • Component: core-libs
  • Sub-Component: java.util:i18n
  • Affected Version: 1.2.0,1.3.0
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • OS: solaris_2.5,solaris_2.6
  • CPU: sparc
  • Submitted: 1999-08-30
  • Updated: 2003-11-05
  • Resolved: 2003-11-05
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
Other
5.0 b28Fixed
Related Reports
Duplicate :  
Duplicate :  
Relates :  
Relates :  
Relates :  
Description

Name: ksC84122			Date: 08/30/99


The javadoc for java.util.GregorianCalendar.setLenient() 
(see java.util.Calendar.setLenient() ) states:
-----
Specify whether or not date/time interpretation is to be lenient.
     With lenient interpretation, a date such as "February 942, 1996"
     will be treated as being equivalent to the 941st day after
     February 1, 1996. With strict interpretation, such dates will
     cause an exception to be thrown.
-----
     
However, if java.util.GregorianCalendar.setLenient(false) is called, 
date of January WEEK_OF_MONTH 6, 1996 is interpreted as 
February 7, 1996 and no exception is thrown. The reason this
is happening is that the GregorianCalendar validation code 
uses getMaximum() to validate non-lenient input instead of getActualMaximum().
(See Bug Id 4147269). 
This behavior should be explicitly specified in the javadoc.
    
======================================================================

Comments
CONVERTED DATA BugTraq+ Release Management Values COMMIT TO FIX: tiger-beta FIXED IN: tiger-beta INTEGRATED IN: tiger-b28 tiger-beta
14-06-2004

EVALUATION This problem should be an implementation bug. As pointed out, it should call getActualMaximum() in the non-lenient mode. masayoshi.okutsu@Eng 2000-02-18
18-02-2000